Re: Looping [was Re: Python and the need for speed]

[Marko Rauhamaa]

Gregory Ewing :

> bartc wrote:
>> Most of my loops start off as endless loops, until I can determine
>> the actual terminating condition, and where it best goes.
>
> Interesting. My experience is quite different. Most of the loops I
> write start off with me thinking "Now I want to do this for each
> element of this collection", which maps straight to a Python for-loop.
>
> In the rare cases where I do use a while loop, usually I have a fairly
> good idea what the terminating condition is going to be.

Here's statistics from a medium-sized project of mine:

   while True:34
   while : 39
   for ... in ...:   158


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

Re: Merging multiple sorted sequences.

[Andre Müller]

Hi,
when you have lists with different lengths and want to zip them, you should
look at itertools.zip_longest

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

Re: Moderating the list [was: Python and the need for speed]

[breamoreboy]

On Thursday, April 13, 2017 at 10:31:22 AM UTC+1, Tim Golden wrote:
> On 13/04/2017 03:39, Jason Friedman wrote:
> >>
> >> However, it's simply a technical fact: the thing which we moderate is the
> >>> mailing list. We can control which posts make it through from the 
> >>> newsgroup
> >>> by blocking them at the gateway. But the posts will continue to appear on
> >>> comp.lang.python which is, as the description says, unmoderated.
> >>>
> >>
> >> TJG
> >
> >
> > Thank you, Tim and Ethan and the other moderators, for performing that
> > function.
> > It makes the reading experience more pleasant for me.
> >
> 
> I looked, for the first time in a long while, at the GG mirror of the 
> newsgroup. Hadn't realised how much of that really nasty all-caps spam 
> we were blocking. (We set up some gateway rules when that started to 
> become a problem so we just don't see it on the mailing list).
> 
> Most of the time we're just binning run-of-the-mill spam. Doesn't take 
> too much effort if you keep on top of it, but it piles up quickly enough 
> if you leave it for a bit!
> 
> TJG

I routinely set all of the upper-case crap to "violent content" on GG just as a 
matter of principle.  There's even been a couple of English versions lately but 
the filters have stopped them, well done :-)

Kindest regards.

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

Re: Swiss Ephemeris

[Peter Henry]

Hi

I hired a programmer to help to extract data for windows 10 64 Bit system

You will be able  generate data and  use for your models,  the idea is to
eventually get Swiss Ephemeris working as phython file
Create folder and use and drop Swedll64.dll and Swetest64.exe into same
folder as spreadsheet

Happy Easter

Peter

On 10 April 2017 at 02:52, Deborah Swanson 
wrote:

> Peter Henry wrote, on Sunday, April 09, 2017 10:53 AM
> >
> > I have a package that has been altered to imported in to
> > python, however I tired to get is working but without success
> > I be missing something obvious
> >
> > The Swiss Ephemeris enable planetary coordinate  to be
> > imported and used in your program
> >
> > Files access https://pypi.python.org/pypi/pyswisseph
> >
> > Many thanks in advance
> >
> > Peter
>
> I've also worked on the problem of getting sweph into Python and have
> mostly struck out so far myself.
>
> I found one reliable means to get sweph's planetary data into Python,
> but it's more or less a cheat. Nonetheless, if you want to see how much
> good it does you, try the Swiss Ephemeris Test Page at
> http://www.astro.com/swisseph/swetest.htm. If you can successfully
> formulate a query useful to your purposes, you can download a csv of
> results, read it into Python, and work from there. Right now I'm working
> on converting some Excel spreadsheets and Excel VBA I use into Python
> and recoding it all, using the CSVs for jumping off points. That works
> pretty well, except the times from swetest are off a bit and I haven't
> figured out why. But I'm concentrating on getting all my VBA code ported
> to Python, and will go back to getting bang on data from sweph after I
> have my code done.
>
> The first thing I tried was to get sweph's C source code into a free
> IDE, but that whole project went down in flames. You can read bits and
> pieces of that misadventure at the tail end of the "Python application
> launcher (for Python code)" thread. I found sweph's C source code at
> some link off "Programming interface to the Swiss Ephemeris" at
> http://www.astro.com/swisseph/swephprg.htm (or maybe it was on
> http://www.astro.com/swisseph/swephinfo_e.htm - I can't easily find it
> now, but the download link is in one of those two pages somewhere.)
>
> Then I tried picking through sweph's C source code, attempting to
> manually reproduce the logic and the calculations in Python. That was a
> highly qualified semi-success because the times were still off, but it
> essentially produces the most basic planetary data. The swetest output
> CSVs were more complete however, and easy to read the planetary data
> into Python from, so I'd pretty much abandoned efforts to "translate"
> the C source code. And now, all my efforts to leverage the C source
> code. Even if successful it would be a lot more time sunk into working
> with a language other than Python, which I likely wouldn't have a use
> for after this project is completed.
>
> However, I have seen bits here and there on this list that are at least
> interesting. Tim Chase mentioned in passing that he encapsulated C
> source code in a class, which may bear looking into. Lutz Horn also gave
> a link for building a Python module to add a C language library to
> Python, which also might be worth checking out:
> https://docs.python.org/3/extending/index.html (I changed the 2 to a 3
> from the link he gave, but you can change it back to 2 if your working
> in a build of Python 2.)
>
> But many thanks for your pypi link to pyswisseph, which I will check
> out. I can reply to this thread after I give it a shot and tell you what
> I think of it. But like I said earlier, that won't be until all my Excel
> VBA code, which jumps off from the sweph bare planetary data, is ported
> to Python and working. Could be awhile yet. And if pyswisseph doesn't
> pan out, I'll likely work on refining the two methods I have for
> producing the planetary data, both of which are only lacking precisely
> accurate time data in my local time, and both are off by only 5-30
> minutes. I easily limped along for years with my Excel spread sheets
> using the swetest CSVs for input, even though my times then were more
> than a day off.
>
> Good luck! (and this venture is a goodly portion of luck...)
>
> Deborah
>
> PS. I've been using medical astrology to look ahead at my medical
> condition for years in advance. And being off by a day or so doesn't
> matter that much when you're looking at trends over the course of years
> and decades. I also have a little software widget to look at the
> planetary data in graphical chart form at any particular second, also
> based on sweph, which has been quite astoundingly accurate in following
> the rather complex kaleidoscope of my symptoms during the course of a
> day. (Though it doesn't do you a bit of good if you forget to look!
> Which is my entire motivation to get it encoded and available with a few
> clicks.) And it is quite useful to know in advance w

Re: Python Command Line Arguments

[breamoreboy]

On Friday, April 14, 2017 at 2:44:09 PM UTC+1, Bernd Nawothnig wrote:
> On 2017-04-13, Jason Friedman wrote:
> >> I have this code which I got from https://www.tutorialspoint.
> >> com/python/python_command_line_arguments.htm The example works fine but
> >> when I modify it to what I need, it only half works. The problem is the
> >> try/except. If you don't specify an input/output, they are blank at the end
> >> but it shouldn't be.
> >>
> >> import getopt
> >> import sys
> >
> > I am guessing you are wanting to parse command-line arguments rather than
> > particularly wanting to use the getopt module.
> > If I am correct you might want to spend your time instead learning the
> > argparse module:
> > https://docs.python.org/3/library/argparse.html
> > https://docs.python.org/3/howto/argparse.html
> 
> He should switch to argparse in any case because getopt is no longer
> supported and does only receive bugfixes.
> 
> Bernd
> 
> -- 
> Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
> haben – und Geld. Die Antisemiten – ein Name der
> ‘Schlechtweggekommenenen’ [Friedrich Nietzsche]

optparse is deprecated, not getopt.

Kindest regards.

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

Announcing SCM Workbench 0.8.6 for Git, Mercurial and Subversion

[Barry Scott]

SCM Workbench features

• Support Subversion (svn), Mercurial (hg) and Git projects.
• Easy to learn and use
• Builtin User Guide describes the operation and features of the 
application.
• Add project wizard can scan for all your existing projects.
• All subversion client operations in a GUI
• Many Git client operations in a GUI
• GUI git rebase
• Some mercurial (hg) client operations in a GUI
• Enhanced operations (subversion rename of modified files etc)
• Support software development workflow
• Builtin GUI diff showing line and character diffs
• Ability to diff between revisions in a files history
• Runs on Windows, Mac OS X and Unix platforms

Please visit http://scm-workbench.barrys-emacs.org/ for downloads, git source, 
user guide and further information on SCM Workbench.

New in 0.8.6
• Dialog feedback has been refactored to give a cleaner user experience 
in the Add project wizard.
• Add basic git stash support.
• Update to use python3.6 and latest PyQt5.
• Fixes for minor issues found by pylint.
• Improvements to build tooling.

Barry

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

Re: Python Command Line Arguments

[breamoreboy]

On Saturday, April 15, 2017 at 6:45:51 PM UTC+1, Grant Edwards wrote:
> On 2017-04-14, Bernd Nawothnig wrote:
> 
> > He should switch to argparse in any case because getopt is no longer
> > supported and does only receive bugfixes.
> 
> In my book, "receiving bug fixes" means it's still supported.
> 
> --
> Grant

Just to reinforce what I said before, optparse is deprecated, not getopt.

Kindest regards.

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

Re: write arrays to disk

[Andre Müller]

Hi,

there are many possible solutions.

You'll need a serialiser to convert the Python object into bytes.
If you wan't to access the data from other applications, you can use json,
xml or other well known formats. Json and XML is in the Python standard
library.
You can also use a database.

As json:
arr = [1, 2, 3, 4]
with open('array.json') as fd:
json.dump(arr, fd)

with open('array.json') as fd:
arr = json.load(fd)

With a bytearray:
arr = bytearray([1, 2, 3, 4])
with open('ba.bin', 'wb') as fd:
fd.write(arr)

with open('ba.bin', 'rb') as fd:
arr = bytearray(fd.read())

Another example with a numpy array:
arr = numpy.array([1, 2, 3, 4], dtype=numpy.int)
with open('array.bin', 'wb') as fd:
arr.tofile(fd)

with open('array.bin', 'rb') as fd:
arr = numpy.fromfile(fd, dtype=numpy.int)

What you should not do:

arr = [1, 2, 3, 4]
with open('plain.txt', 'wt') as fd:
fd.write(repr(arr))

with open('plain.txt') as fd:
arr = eval(fd.read())

If you need to store more data, you should think about a database.

Greetings
Andre

 schrieb am So., 16. Apr. 2017 um 14:29 Uhr:

> Hi,
>
> I'm new on Python software. I would like to write on disk arrays in
> binary or ascii format. Can someone please help me?
>
> Thanks,
>
> Conrado
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Hi! i need some help with a program in python on Raspberry pi3.

[breamoreboy]

On Friday, April 14, 2017 at 3:27:29 PM UTC+1, Kasper wrote:
> every time i run the program i get this messeage:
> 
> Traceback (most recent call last):
>   File "smartmirror.py", line 159, in get_weather
> temprature2 = "%S%S" % (str(int(weather_obj['currently']['temperature'])),
> degree_sign)
> KeyError: 'currently'
> Error: 'currently'. Cannot get weather.
> 
> How do i fix that?
> 
> Here is the program:
> 
> r = requests.get(weather_req_url)
> weather_obj = json.loads(r.text)
> 
> degree_sign= u'\N{DEGREE SIGN}'
> temperature2 = "%s%s" % 
> (str(int(weather_obj['currently']['temperature'])), degree_sign)

Find the correct name for the key by printing out `weather_obj`.  At least I 
think so, as the line above does not match the line that you've given.

Kindest regards.

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

Re: Regular Expressions, Speed, Python, and NFA

[breamoreboy]

On Friday, April 14, 2017 at 4:12:27 PM UTC+1, Malik Rumi wrote:
> I am running some tests using the site regex101 to figure out the correct 
> regexs to use for a project. I was surprised at how slow it was, constantly 
> needing to increase the timeouts. I went Googling for a reason, and solution, 
> and found Russ Cox’s article from 2007: 
> https://swtch.com/~rsc/regexp/regexp1.html . I couldn’t understand why, if 
> this was even remotely correct, we don’t use NFA in Python, which led me here:
> 
> https://groups.google.com/forum/#!msg/comp.lang.python/L1ZFI_R2hAo/C12Nf3patWIJ;context-place=forum/comp.lang.python
>  where all of these issues were addressed. Unfortunately, this is also from 
> 2007. 
> 
> BTW, John Machin in one of his replies cites Navarro’s paper, but that link 
> is broken. Navarro’s work can now be found at 
> http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.21.3112&rep=rep1&type=pdf
>  But be forewarned, it is 68 pages of dense reading. I am not a computer 
> science major. I am not new to Python, but I don’t think I’m qualified to 
> take on the idea of creating a new NFA module for Python.  
> 
> I am not a computer science major. I am not new to Python, but I don’t think 
> I’m qualified to take on the idea of creating a new NFA module for Python.  
> Nor am I entirely sure I want to try something new (to me) like TRE. 
> 
> Most threads related to this topic are older than 2007. I did find this 
> https://groups.google.com/forum/#!searchin/comp.lang.python/regex$20speed%7Csort:relevance/comp.lang.python/O7rUwVoD2t0/NYAQM0mUX7sJ
>  from 2011 but I did not do an exhaustive search. 
> 
> The bottom line is I wanted to know if anything has changed since 2007, and 
> if there is a) any hope for improving regex speeds in Python, or b) some 3rd 
> party module/library that is already out there and solves this problem? Or 
> should I just take this advice?
> 
> 
> Thanks.

Check out https://pypi.python.org/pypi/regex and for a little light background 
reading please see http://bugs.python.org/issue2636

Kindest regards.

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

Python's help() function is awesome

[Steve D'Aprano]

If you're not using the help() command in the interactive interpreter,
you're missing out on a lot.

I recently discovered that help() is even cleverer than I knew. I knew it
picked up on objects' doc strings, but what happens if the object doesn't
have a doc string?

Let's find out!

Here's a tiny module with a couple of toy functions. Save this
as "module.py":

# --- cut here ✂ 

def greet(name='world'):
"""Hello world, with optional name."""
print ("Hello, %s" % name)

# The insult() function insults the caller.
# Pass the number of insults to use, and an optional name.
def insult(number, name=None):
if name is None or name == '':
name = 'Anonymous Coward'
print(name)
for i in range(number):
if i%2 == 0:
print("Your mother smells of elderberries!")
else:
print("And your father was a hamster!")

def goodbye():
# Say goodbye.
print("Goodbye cruel world!")

# --- ✂ ---


Now start up the interactive interpreter and import the module:

py> import module
py> help(module)


and you should see something like this:


Help on module module:

NAME
module

FUNCTIONS
goodbye()

greet(name='world')
Hello world, with optional name.

insult(number, name=None)
# The insult() function insults the caller.
# Pass the number of insults to use, and an optional name.

FILE
/home/steve/module.py



Not only does it pick up the docstring for greet(), but it picks up the
comment just prior to the function definition of insult(). Alas, as of
Python 3.5 it doesn't recognise the comments in the goodbye() function --
perhaps because they're conceptually part of the implementation, not the
interface.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Bigotry and hate speech on the python mailing list

[Rurpy via Python-list]

A couple weeks ago a frequent poster here (Steve D'Aprano 
) called another participant an "ugly american" 
[*1].  This was followed just a couple weeks later with another post from Mr. 
D'Aprano attacking a participant as "an old man" who can't understand new 
technology, a blatant example of ageism [*2].

The PSF's Diversity statement [*3] explicitly calls out "age" and "national 
origin" as examples of personal attributes NOT to be used as verbal weapons.  
It is also neither "considerate" or "respectful" as described in the PSF Code 
of Conduct [*4] to use national origin or age to attack someone.  In both cases 
it is reasonable to believe that some Americans or older people will, after 
reading Mr. D'Aprano's posts, feel uncomfortable posting to this list or 
responding to Mr. D'Aprano specifically on other issues, because they might 
well be attacked on the same grounds.  Further, failure to censure Mr. 
D'Apano's comments communicates that bigotry is acceptable here which 
understandably would give pause to members of other groups often subject to 
bigotry.

I posted a message in objection [*5] that got no response, I would like to 
think because it got lost in a long thread, not because bigotry is acceptable 
here and the CoC is just window dressing.

I also believe the PSF is registered in the US as a tax exempt organization 
which means it has a legal obligation not to permit discrimination against 
people based on national origin or age (and other distinctions).

Would someone from the PSF please publicly clarify exactly why the two cases 
cited are being treated as acceptable discourse in this list?

I am not trying to create a controversy for its own sake; when I first started 
reading this list many years ago I was appalled by rudeness displayed to 
newcomers coupled with instant anger by the regulars towards non-regulars at 
the slightest hint of rudeness (even imagined) towards them.  A decade later 
things have not changed much.  If I posted a remark about "dirty Chinese" (c.f. 
"ugly American") I would be (justifiably) slammed and likely ejected from the 
list.  Or if claims that not understanding new tech is a product of age are ok, 
then why can't I say disparagingly that someone "programs like a girl"?  When a 
popular poster here says such things, it is not only given a pass, it is 
actually defended!  

I am not personally in favor of censorship; the best response to hate speech is 
a reasoned counter argument IMO.  But if you are going to have a CoC, it must 
be applied even-handedly.  You cannot apply it when you want to unpopular 
posters and ignore it when it comes to a one of the clique of regulars.


[*1] https://mail.python.org/pipermail/python-list/2017-April/720531.html
[*2] https://mail.python.org/pipermail/python-list/2017-April/721106.html
[*3] https://www.python.org/community/diversity/
[*4] https://www.python.org/psf/codeofconduct/
[*5] https://mail.python.org/pipermail/python-list/2017-April/721135.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry and hate speech on the python mailing list

[Marko Rauhamaa]

Rurpy :

> If I posted a remark about "dirty Chinese" (c.f. "ugly American") I
> would be (justifiably) slammed and likely ejected from the list. Or if
> claims that not understanding new tech is a product of age are ok,
> then why can't I say disparagingly that someone "programs like a
> girl"? When a popular poster here says such things, it is not only
> given a pass, it is actually defended!

In my experience, the bar for banning participants is pretty high, and
rightly so. Careless statements, insults or bigotry haven't been enough,
but repeated, personal harassment of an individual have resulted in
action.

You are free to set a bar of your own. It's called plonking.

BTW, as a middle-aged American, I don't get offended by slurs against
Americans or old people. I first try to see if there's a grain of truth
behind the generalization, and if not, I will simply have a lower
opinion of the judgement of whoever said it.

Cultures are real, distinct things, and every culture has
(objectively/subjectively) less desirable aspects. Age does have
measurable effects on our performance. Making generalizations doesn't
automatically make a statement "hate speech."

Let me offer a bigoted joke I heard the other day:

   Wife to programmer: "Go to the store and get a gallon of milk. If
   they have eggs, get six."

   ...

   Wife to programmer: "Why on earth did you buy six gallons of milk?"

   Programmer: "They had eggs."


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

Re: Bigotry and hate speech on the python mailing list

[Ben Finney]

Rurpy via Python-list  writes:

> A couple weeks ago a frequent poster here (Steve D'Aprano
> ) called another participant an "ugly
> american" [*1].

He gave no explicit reference, and so I can see why you would think he
did what you describe.

In fact, though, Steven in the message you link to stated:

If you think that all these people, and hundreds of millions more,
will just "quietly change the filename" to ASCII because you're too
lazy, self-centred and arrogant to move on from 1963, then you truly
are an example of the Ugly American.

Again, it's not stated explicitly what Steven is referring to, so I can
see why you would initially be confused.

But by now, with plenty of time to look into what was actually being
discussed, surely you have noticed that Steven was *not* using physical
appearance as an insult; nor was he using mere national origin as an
insult.

Rather, the message is a reference to the Ugly American. Note the
capitals Steven used; that is how a title is spelled.

The title “Ugly American” is a reference to a stereotypical *attitude
and behaviour*, given that name by the 1958 political novel of the same
name https://en.wikipedia.org/wiki/The_Ugly_American>.

This is not using ugliness, nor American nationality, as an insult. It
is a reference to objectionable behaviour as Steven described.

Whether you agree that the behaviour described is objectionable, you can
hopefully agree that naming objectionable behaviour to discourage it, is
not in itself something to be discouraged.


I can fault Steven for assuming that the reader would, by the novel's
title alone, know of a mid-20th century novel reference or the
stereotype it describes. That's not a breach of PSF CoC.

I can fault Steven for assuming that those who *don't* get the reference
would not leap to the conclusion you've leapt to: that he was using
national origin as an insult. That assumption on his part is
unfortunate, and perhaps an apology would be good. Regardless of that,
it is not a breach of the PSF CoC.

What I can't fault him for is using national origin as a verbal weapon.
He simply did not do that in the message you link to.

> Further, failure to censure Mr. D'Apano's comments communicates that
> bigotry is acceptable here which understandably would give pause to
> members of other groups often subject to bigotry.

Similarly, my elaboration here – to give it the prominence you rightly
say that the original sub-thread did not achieve – should demonstrate to
you that D'Aprano's comments did not constitute bigotry against any
national origin.

The charge of bigotry is a strong one here, rightly so, and I think you
for taking it seriously. Will you drop that charge now? If you won't, I
think you need to show how this analysis is incorrect.

-- 
 \   “Let others praise ancient times; I am glad I was born in |
  `\  these.” —Ovid (43 BCE–18 CE) |
_o__)  |
Ben Finney

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

Re: Static typing [was Re: Python and the need for speed]

[Steve D'Aprano]

On Sun, 16 Apr 2017 02:27 pm, Steve D'Aprano wrote:

> Are you aware that optional static typing CANNOT be used for optimization?

I think I've over-stated that. Considerably. In other words, I was wrong.

As Steve Yegge points out, dynamic languages like Smalltalk and Lisp were,
back in the 1980s, heavily optimized and were competitive with
statically-typed languages like C:

http://steve-yegge.blogspot.com.au/2008/05/dynamic-languages-strike-back.html

While this is true:

> Since it is *optional*, it is only a hint, not a fact. You can tell the
> compiler that you believe that n will be an int, but it's not guaranteed.
> As the Dude says, the type hint is
> 
> that's, like, only your opinion man
> 
> and the compiler cannot trust it. It must still guard the operation with a
> runtime check that n actually is an int, 

The conclusion that I drew:

> and so you lose most or all of 
> the benefit of telling the compiler that it's an int. 

is not necessarily the case. If you're doing lots of little operations on
disparate variables, with lots and lots of guard checks and not much
optimized code, it will go badly for you, but on the other hand for big
loops with only a few up-front checks and predictable types, there may be
opportunities for optimization.

Honestly, I'm not quite sure what I was thinking: that sort of "optimized
code with a guard" is exactly what Psycho does, and what FATPython is
hoping to bring to CPython some day.

At the present time, the state of the art of gradual typing is still keeping
the emphasis on optional static typing for *correctness*, not optimization:

http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/

but research does continue into using gradual typing for optimizations:

http://dl.acm.org/citation.cfm?id=2069175


[...]
> Python's gradual typing is not about optimization, it is about testing
> program correctness and helping to find bugs at compile time*. 

That's the motivation for MyPy.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Static typing [was Re: Python and the need for speed]

[Steve D'Aprano]

On Mon, 17 Apr 2017 04:18 pm, Paul Rubin wrote:

> Steve D'Aprano  writes:
>> Since it is *optional*, it is only a hint, not a fact. You can tell the
>> compiler that you believe that n will be an int, but it's not guaranteed.
> 
> The runtime could check at the entry to the function that n is an int,
> and then it wouldn't have to keep re-checking on the inside of a loop.
> That's what a JIT compiler does in the absence of annotations, more or
> less; 

Funnily enough, in the very post you quote, I did write:

"There are clever Just In Time compiler tricks that can optimize the code,
which is what Psycho did and PyPy still does, but they don't need type
hints."

The reason being that at runtime the compiler knows the type of the value
and the type hint is redundant.

On the other hand, there's Cython. Cython claims *not* to be a JIT compiler,
but I don't really understand why. As I understand it, Cython can operate
in two ways:

(1) as a Python interpreter, with some optimizations switched on or off at
runtime according to the types and/or values actually used by the program;

(2) as a pseudo-Python to C compiler, allowing you to write Python-ish code
that is compiled to C (plus a Python runtime for anything that's too hard
to translate into C).

I'm not sure why the Cython devs maintain this is not a JIT compiler.
Perhaps I misunderstand something.


> but the annotations make life easier for ahead-of-time compilers. 
> Again this type of thing has been standard in Lisp since the 1960's.

Indeed it has. The state of the art of optimizations for dynamically typed
languages has been badly neglected for many years. Fortunately in the last
decade or so there's been a lot more interest in this.

See, for example, Steve Yegge:

http://steve-yegge.blogspot.com.au/2008/05/dynamic-languages-strike-back.html



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Bigotry and hate speech on the python mailing list

[Rustom Mody]

On Monday, April 17, 2017 at 4:09:34 PM UTC+5:30, Ben Finney wrote:
> The charge of bigotry is a strong one here, rightly so, and I think you
> for taking it seriously. Will you drop that charge now? If you won't, I
> think you need to show how this analysis is incorrect.

On the same day that (I saw) this original complaint, I also saw this article
http://nymag.com/daily/intelligencer/2017/04/the-duke-lacrosse-scandal-and-the-birth-of-the-alt-right.html

which I believe serves as an accurate diagnoser for the malaise — political 
and then spreading — of our times
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry and hate speech on the python mailing list

[Rustom Mody]

On Monday, April 17, 2017 at 3:09:44 PM UTC+5:30, Marko Rauhamaa wrote:
> Rurpy :
> 
> > If I posted a remark about "dirty Chinese" (c.f. "ugly American") I
> > would be (justifiably) slammed and likely ejected from the list. Or if
> > claims that not understanding new tech is a product of age are ok,
> > then why can't I say disparagingly that someone "programs like a
> > girl"? When a popular poster here says such things, it is not only
> > given a pass, it is actually defended!
> 
> In my experience, the bar for banning participants is pretty high, and
> rightly so. Careless statements, insults or bigotry haven't been enough,
> but repeated, personal harassment of an individual have resulted in
> action.
> 
> You are free to set a bar of your own. It's called plonking.
> 
> BTW, as a middle-aged American, I don't get offended by slurs against
> Americans or old people. I first try to see if there's a grain of truth
> behind the generalization, and if not, I will simply have a lower
> opinion of the judgement of whoever said it.
> 
> Cultures are real, distinct things, and every culture has
> (objectively/subjectively) less desirable aspects. Age does have
> measurable effects on our performance. Making generalizations doesn't
> automatically make a statement "hate speech."
> 
> Let me offer a bigoted joke I heard the other day:
> 
>Wife to programmer: "Go to the store and get a gallon of milk. If
>they have eggs, get six."
> 
>...
> 
>Wife to programmer: "Why on earth did you buy six gallons of milk?"
> 
>Programmer: "They had eggs."

Thanks Marko... Hilarious [Sent it to some friends]
I personally feel racism (or in this case more technically communalism)
needs to be celebrated not disparaged
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python's help() function is awesome

[Terry Reedy]

On 4/17/2017 5:31 AM, Steve D'Aprano wrote:

If you're not using the help() command in the interactive interpreter,
you're missing out on a lot.

I recently discovered that help() is even cleverer than I knew. I knew it
picked up on objects' doc strings, but what happens if the object doesn't
have a doc string?

Let's find out!

Here's a tiny module with a couple of toy functions. Save this
as "module.py":

# --- cut here ✂ 

def greet(name='world'):
"""Hello world, with optional name."""
print ("Hello, %s" % name)

# The insult() function insults the caller.
# Pass the number of insults to use, and an optional name.
def insult(number, name=None):
if name is None or name == '':
name = 'Anonymous Coward'
print(name)
for i in range(number):
if i%2 == 0:
print("Your mother smells of elderberries!")
else:
print("And your father was a hamster!")

def goodbye():
# Say goodbye.
print("Goodbye cruel world!")

# --- ✂ ---


Now start up the interactive interpreter and import the module:

py> import module
py> help(module)


and you should see something like this:


Help on module module:

NAME
module

FUNCTIONS
goodbye()

greet(name='world')
Hello world, with optional name.

insult(number, name=None)
# The insult() function insults the caller.
# Pass the number of insults to use, and an optional name.


When I ran the module instead of importing it, help(insult) printed the 
same.  The pydoc function wrapped by help must be going back to the 
source, as I believe that comments are left behind when the source is 
compiled.  I did not know this either.  A comment before the def must 
have once been standard.



FILE
/home/steve/module.py



Not only does it pick up the docstring for greet(), but it picks up the
comment just prior to the function definition of insult(). Alas, as of
Python 3.5 it doesn't recognise the comments in the goodbye() function --
perhaps because they're conceptually part of the implementation, not the
interface.



--
Terry Jan Reedy


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

Re: Looping [was Re: Python and the need for speed]

[Terry Reedy]

On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:

Gregory Ewing :


bartc wrote:

Most of my loops start off as endless loops, until I can determine
the actual terminating condition, and where it best goes.


Interesting. My experience is quite different. Most of the loops I
write start off with me thinking "Now I want to do this for each
element of this collection", which maps straight to a Python for-loop.

In the rare cases where I do use a while loop, usually I have a fairly
good idea what the terminating condition is going to be.


Here's statistics from a medium-sized project of mine:

   while True:34
   while : 39
   for ... in ...:   158


As I posted previously, the ratio of for-loops in the stdlib is about 7 
to 1.


--
Terry Jan Reedy

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

Re: Looping [was Re: Python and the need for speed]

[Marko Rauhamaa]

Terry Reedy :

> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>> Here's statistics from a medium-sized project of mine:
>>
>>while True:34
>>while : 39
>>for ... in ...:   158
>
> As I posted previously, the ratio of for-loops in the stdlib is about 7
> to 1.

What I notice in my numbers is that about one half of my while loops are
"while True", and about a third of my loops are while loops.


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

creating vector from df.intertuples

[Richard Medina]

I want to create a vector from a dataframe in a loop. Then I want to create a 
new column from this vector.

for row in df.itertuples():
mm  = str(row.t)  #selecting "t" column
nn = get_sec(mm) #this function converts time to seconds
df["s"] = nn #I want to add my new vector to a new "s" column in my df
print(df.head())#only gives me the last number in the "nn" column.


Any help is appreciated.
Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

[ANN] kubetop 17.4.17.1

[Jean-Paul Calderone]

Hello all,

I'm pleased to announce the initial release of kubetop, a command-line tool
in the style of top(1) for displaying current usage and activity of a
Kubernetes cluster.

kubetop 17.4.17.1 will format information about your Kubernetes cluster
like this:

kubetop - 13:02:57
Node 0 CPU%   9.80 MEM% 57.97 (   2 GiB/   4 GiB)  POD%  7.27 (  8/110) Ready
Node 1 CPU%  21.20 MEM% 59.36 (   2 GiB/   4 GiB)  POD%  3.64 (  4/110) Ready
Node 2 CPU%  99.90 MEM% 58.11 (   2 GiB/   4 GiB)  POD%  7.27 (  8/110) Ready
Pods:   20 total0 running0 terminating0 pending
 POD   (CONTAINER)%CPU MEM   %MEM
s4-infrastructure-3073578190-2k2vw75.5  782.05 MiB  20.76
  (subscription-converger)72.7  459.11 MiB
 (grid-router) 2.7   98.07 MiB
 (web) 0.1   67.61 MiB
(subscription-manager) 0.0   91.62 MiB
   (foolscap-log-gatherer) 0.0   21.98 MiB
   (flapp) 0.0   21.46 MiB
  (wormhole-relay) 0.0   22.19 MiB


kubetop is meant as a handy tool to use at the spur of the moment.  It is
not intended to replace a real monitoring system.

kubetop's presentation is preliminary and a work in progress.
Contributions welcome.

You can find kubetop on PyPI  and
GitHub .  Install it in the
usual way:

pip install kubetop


Thanks to Least Authority Enterprises  for
sponsoring this development.

Jean-Paul Calderone
http://as.ynchrono.us/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: creating vector from df.intertuples

[Peter Otten]

Richard Medina wrote:

> I want to create a vector from a dataframe in a loop. Then I want to
> create a new column from this vector.
> 
> for row in df.itertuples():
> mm  = str(row.t)  #selecting "t" column
> nn = get_sec(mm) #this function converts time to seconds
> df["s"] = nn #I want to add my new vector to a new "s" column in
> my df
> print(df.head())#only gives me the last number in the "nn" column.

I think you need to build the whole column before adding it to the 
DataFrame.

# untested
df["s"] = [get_sec(str(t)) for t in row.t]

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

Buffers and pointers (Py3.4)

[Rob Gaddi]

So long as we're all feeling so concerned about speed lately...

I've got a piece of hardware that allows me to call a C library that 
calls an ioctl() that kicks off a DMA transfer and moves data between 
process memory and external hardware.  I would like a way to turn an 
arbitrary object implementing the buffer protocol into a pointer so that 
I can pass that pointer to the library to be passed to the hardware to 
stream my data.


The obvious question on your minds is why on earth am I doing this. 
Example case: my hardware is being used as a bridge to talk to a 16 
channel transient digitizer, acquiring data at 500 ksps per channel.  I 
would like my Python application to be able to acquire, say, 10M samples 
per channel.  I can have a list of 16 10M NumPy arrays, and every 5 ms I 
can request a single DMA transfer to grab all the new data that's been 
acquired and push it, zero-copy, into my arrays before the hardware 
FIFOs get full and I start losing data.


If I knew the buffers would always be NumPy arrays I could use 
ndarray.ctypes.data to get the pointer.  Always ctypes buffers, I could 
just use ctypes.addressof.  In either case I can flip them into 
memoryviews, but nothing seems to give me a pointer from that. 
Bytearrays, array.arrarys..., I've got nothin'.


If I were writing this as a C extension, getting that information from 
any buffer object would be trivial, but that changes my project from a 
pure Python wrapper using ctypes to a mixed language project with 
compile dependencies and mental headaches.


  buffertype = c_uint8 * size
  return addressof(buffertype.from_buffer(buf, offset))

works but is inefficient and woefully inelegant.  I saw some discussion 
on the ctypes bug tracker https://bugs.python.org/issue27274 about this 
nearly a year ago, but no actual action.


I really want to take all of this low-level horribleness, wrap it up 
into a higher-level API, and never be subject to the gory details again. 
 This pointer thing is about the last hangup.  Ideas?


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

GPUs with various tools

[Jeffrey Layton]

Good afternoon,

Since I just got a nice GTX 1050 card, I would like to exercise it with Python. 
In particular, I'm curious about tools such as SciPy, Pandas, Numpy, etc., that 
can take advantage of GPUs so I don't have to write any GPU code. 

For example, can I solve an A X = B linear problem on GPUs if it's faster than 
running it on the CPUs.

I'm working with Continuum's Accelerate and I'm slowly learning PyCUDA but I'm 
looking for something that's already coded.

Any suggestions?

Thanks!

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

Re: Looping [was Re: Python and the need for speed]

[Ben Bacarisse]

Marko Rauhamaa  writes:

> Terry Reedy :
>
>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>>> Here's statistics from a medium-sized project of mine:
>>>
>>>while True:34
>>>while : 39
>>>for ... in ...:   158
>>
>> As I posted previously, the ratio of for-loops in the stdlib is about 7
>> to 1.
>
> What I notice in my numbers is that about one half of my while loops are
> "while True", and about a third of my loops are while loops.

I fond the proportion on while True: loops surprising.  Is there
something about Python that encourages that kind of loop?

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

Re: Looping [was Re: Python and the need for speed]

[bartc]

On 17/04/2017 19:02, Ben Bacarisse wrote:

Marko Rauhamaa  writes:


Terry Reedy :


On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:

Here's statistics from a medium-sized project of mine:

   while True:34
   while : 39
   for ... in ...:   158


As I posted previously, the ratio of for-loops in the stdlib is about 7
to 1.


What I notice in my numbers is that about one half of my while loops are
"while True", and about a third of my loops are while loops.


I fond the proportion on while True: loops surprising.  Is there
something about Python that encourages that kind of loop?



A few things:

(1) Python doesn't have the equivalent of C's comma operator, and no 
assignment in expressions. So if a condition relies on such set-up code, 
it can't do this:


   while (c=nextc())!=0:

But has to do this or use extra logic:

   while 1:
  c=nextc()
  if c==0: break

(2) There are exceptions ('raise') as an extra means of breaking out of 
such loops (as well as return, break, and exit()


(3) There's 'yield' too, as I've just seen this example:

while True:
   yield []

So there are more excuses to make use of it. Plus Python programmers may 
be more averse to using convoluted logic just to avoid a 'break' in the 
middle of a loop.



--
bartc

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

Re: Looping [was Re: Python and the need for speed]

[Marko Rauhamaa]

Ben Bacarisse :

> Marko Rauhamaa  writes:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> I fo[u]nd the proportion on while True: loops surprising. Is there
> something about Python that encourages that kind of loop?

Here's a typical example of such a loop in Python (ver 2):

while True:
try:
snippet = os.read(rdfd, 1000)
except OSError as e:
if e.errno == errno.EAGAIN:
return
raise
if not snippet:
break
self.stdout_snippets.append(snippet)

I find myself writing similar loops in C a lot, as well.


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

Re: Buffers and pointers (Py3.4)

[Chris Angelico]

On Tue, Apr 18, 2017 at 3:58 AM, Rob Gaddi
 wrote:
> If I were writing this as a C extension, getting that information from any
> buffer object would be trivial, but that changes my project from a pure
> Python wrapper using ctypes to a mixed language project with compile
> dependencies and mental headaches.
>
>   buffertype = c_uint8 * size
>   return addressof(buffertype.from_buffer(buf, offset))
>
> works but is inefficient and woefully inelegant.

Have you considered Cython? It can massively simplify a lot of the
work in doing this kind of thing.

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

Re: Looping [was Re: Python and the need for speed]

[Mikhail V]

On 17 April 2017 at 04:00, Steve D'Aprano  wrote:
> On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote:
>
>> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano
>>  declaimed the following:
>>
>>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
>>>
 But people just don't want it.
>>>
>>>Damn straight. Now you get it. It's not about how easy it is to implement,
>>>it's about whether it is needed and wanted. It isn't needed, and it isn't
>>>wanted.
>>>
>>
>> Let's go all the way, and just get rid of "while ".
>
> Sure, why not? If it's your language, you can make it as minimalist or
> maximalist as you like. You get to choose.
>

I think it is right not to touch anything for .py file rules.
Seriously there are much more problems, and better code editors
should adress those, not current syntax.


As for loops, well, if we speak of some 'my' language,
it could be interesting whether there are common patterns.
But is it on-topic here to speak of, say PyBasic2020 fantasy
language?

For real-time application development the amount of
"while(condition)" vs "while True" can play bad jokes
with readability.
I would find such looping schema simpler:

loop:
if contitioin 1 : contitioin_break = 1
blabla bla = bla  + foo
make something
make something
if contitioin 2 : contitioin_break = 1
if contitioin 3 : contitioin_break = 0
if contitioin_break :  *break
/loop


Anyway it is just question where to show this last line,
or to make an emphasis on it.
so I'd just leave it there, for me it helps when I imagine
a cascade of functions and my eyes go down to the
bottom.  If I have kilometers of "if"s inside the loop,
then hiding one line can become more a problem than an aid.

Constructs like "repeat 100 times {}" or other sort of
"let's pronounce it in English" found in
some languages looks sort of confusing, it takes
me time to "unwrap" their sense into a cascade
especially when there are many different keywords.


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

Re: Looping [was Re: Python and the need for speed]

[Grant Edwards]

On 2017-04-17, Ben Bacarisse  wrote:
> Marko Rauhamaa  writes:
>
>> Terry Reedy :
>>
>>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
 Here's statistics from a medium-sized project of mine:

while True:34
while : 39
for ... in ...:   158
>>>
>>> As I posted previously, the ratio of for-loops in the stdlib is about 7
>>> to 1.
>>
>> What I notice in my numbers is that about one half of my while loops are
>> "while True", and about a third of my loops are while loops.
>
> I fond the proportion on while True: loops surprising.  Is there
> something about Python that encourages that kind of loop?

That's how you read data from a socket/pipe/file.

-- 
Grant Edwards   grant.b.edwardsYow! Your CHEEKS sit like
  at   twin NECTARINES above
  gmail.coma MOUTH that knows no
   BOUNDS --

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

Re: Bigotry and hate speech on the python mailing list

[Paul Rubin]

Rurpy  writes:
> A couple weeks ago a frequent poster here (Steve D'Aprano
> ) called another participant an "ugly
> american"

Oh stop trolling.  Ugly American was a 1950s thing, now just amusing.
And context matters.  Steven, please try to be a little more attentive
to people's delicate feefees in the future.  Rurpy, should that take
care of it?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Static typing [was Re: Python and the need for speed]

[Paul Rubin]

Steve D'Aprano  writes:
> On the other hand, there's Cython. Cython claims *not* to be a JIT compiler,

One of the uses of "JIT compiler" these days is what's sometimes called
a tracing JIT, like PyPy or LuaJIT or the Javascript flavor-of-the-week.
That means it interprets the program while collecting execution traces
to figure out the actual types the program uses at runtime, then
generates machine code for those specific code paths, with some guards
in case an unexpectedly typed value shows up.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: GPUs with various tools

[Paul Rubin]

Jeffrey Layton  writes:
> I'm working with Continuum's Accelerate and I'm slowly learning PyCUDA
> but I'm looking for something that's already coded.

TensorFlow has good Python bindings.  That's probably the best way to
get started.
-- 
https://mail.python.org/mailman/listinfo/python-list

Unable to use Python IDLE after downloading the application

[ASHISH A]

Hi Team,

I have a 64 bit system with Windows 801 Pro OS. I tried to install Python
3.6.1 from the below link :
https://www.python.org/downloads/

It automatically downloaded that 32 bit Python application and tried to
launch IDLE (32 bit). I could not launch IDLE and it gave me an error
saying DLL file missing (attached snapshot). I have downloaded the DLL file
and also installed Microsoft C++ redistributable 2015.(After following
steps on you-tube to fix such DLL issues).

I am still unable to launch IDLE . Could you please let me know if the
issue is because of the 32 bit version of Python on my 64 bit laptop ?
Because the DLL file can not be an issue as i have already fixed it.


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

Re: Unable to use Python IDLE after downloading the application

[ASHISH A]

PFA the snapshot of the error message..


Regards
Ashish

On Mon, Apr 17, 2017 at 11:06 PM, ASHISH A  wrote:

> Hi Team,
>
> I have a 64 bit system with Windows 801 Pro OS. I tried to install Python
> 3.6.1 from the below link :
> https://www.python.org/downloads/
>
> It automatically downloaded that 32 bit Python application and tried to
> launch IDLE (32 bit). I could not launch IDLE and it gave me an error
> saying DLL file missing (attached snapshot). I have downloaded the DLL file
> and also installed Microsoft C++ redistributable 2015.(After following
> steps on you-tube to fix such DLL issues).
>
> I am still unable to launch IDLE . Could you please let me know if the
> issue is because of the 32 bit version of Python on my 64 bit laptop ?
> Because the DLL file can not be an issue as i have already fixed it.
>
>
> Regards
> Ashish
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unable to use Python IDLE after downloading the application

[ASHISH A]

Hi Team,

I also tried installing the 64 bit Python and now i get the attached
snapshot as error message,


Regards
Ashish


On Mon, Apr 17, 2017 at 11:06 PM, ASHISH A  wrote:

> Hi Team,
>
> I have a 64 bit system with Windows 801 Pro OS. I tried to install Python
> 3.6.1 from the below link :
> https://www.python.org/downloads/
>
> It automatically downloaded that 32 bit Python application and tried to
> launch IDLE (32 bit). I could not launch IDLE and it gave me an error
> saying DLL file missing (attached snapshot). I have downloaded the DLL file
> and also installed Microsoft C++ redistributable 2015.(After following
> steps on you-tube to fix such DLL issues).
>
> I am still unable to launch IDLE . Could you please let me know if the
> issue is because of the 32 bit version of Python on my 64 bit laptop ?
> Because the DLL file can not be an issue as i have already fixed it.
>
>
> Regards
> Ashish
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Buffers and pointers (Py3.4)

[eryk sun]

On Mon, Apr 17, 2017 at 5:58 PM, Rob Gaddi
 wrote:
> buffertype = c_uint8 * size
> return addressof(buffertype.from_buffer(buf, offset))
>
> works but is inefficient and woefully inelegant.

A lot of the cost there is in creating buffertype, but why do you need
that? You can use c_char.from_buffer if all you need is the base
address.

import ctypes

def addressof_buffer(buf):
return ctypes.addressof(ctypes.c_char.from_buffer(buf))

>>> b = bytearray(b'spam')
>>> addressof_buffer(b)
2619159025048
>>> ctypes.string_at(2619159025048, 5)
b'spam\x00'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unable to use Python IDLE after downloading the application

[eryk sun]

On Mon, Apr 17, 2017 at 9:06 PM, ASHISH A  wrote:
>
> I could not launch IDLE and it gave me an error saying DLL file missing
> (attached snapshot).

python-list doesn't send attachments. Please do your best to
paraphrase error messages that can't be pasted as plain text.

> I have downloaded the DLL file

I hope you didn't download a system DLL from some arbitrary website,
which could contain malware. Only get Windows updates from Microsoft.

> and also installed Microsoft C++ redistributable 2015.(After following steps
> on you-tube to fix such DLL issues).

You didn't need the full C++ redistributable. If it's an error due to
the Universal C runtime, then you should install KB3118401 for your
version of Windows, which I presume is x64 Windows 8.1.

https://support.microsoft.com/en-us/kb/3118401
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry and hate speech on the python mailing list

[Ben Finney]

Paul Rubin  writes:

> Rurpy  writes:
> > A couple weeks ago a frequent poster here (Steve D'Aprano
> > ) called another participant an "ugly
> > american"
>
> Oh stop trolling.

Paul, that is uncalled for. The charge of bigotry is not to be lightly
dismissed, and we do want to foster an environment here where people
will feel welcome.

> Steven, please try to be a little more attentive to people's delicate
> feefees in the future. Rurpy, should that take care of it?

No, that doesn't do it. Taking care of people's feelings is an essential
part of keeping a community healthy and welcoming, and your belittling
does not help with that.

-- 
 \“Choose mnemonic identifiers. If you can't remember what |
  `\mnemonic means, you've got a problem.” —Larry Wall |
_o__)  |
Ben Finney

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

Re: Looping [was Re: Python and the need for speed]

[Gregory Ewing]

Marko Rauhamaa wrote:

What I notice in my numbers is that about one half of my while loops are
"while True", and about a third of my loops are while loops.


Out of curiosity, what proportion of your 'while True' loops
are infinite? (I.e. no break, return or raise in the loop.)

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

Re: Looping [was Re: Python and the need for speed]

[Paul Rubin]

Ben Bacarisse  writes:
>   c = sys.stdin.read(1)
>   while c == ' ':
>   c = sys.stdin.read(1)

c = itertools.dropwhile(
 lambda c: c==' ',
 iter(lambda: sys.stdin.read(1),None)
 ).next()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Looping [was Re: Python and the need for speed]

[Ben Bacarisse]

Marko Rauhamaa  writes:

> Ben Bacarisse :
>
>> Marko Rauhamaa  writes:
>>> What I notice in my numbers is that about one half of my while loops
>>> are "while True", and about a third of my loops are while loops.
>>
>> I fo[u]nd the proportion on while True: loops surprising. Is there
>> something about Python that encourages that kind of loop?

(Thanks for th type correction.  There is also s/of/on/.)

> Here's a typical example of such a loop in Python (ver 2):
>
> while True:
> try:
> snippet = os.read(rdfd, 1000)
> except OSError as e:
> if e.errno == errno.EAGAIN:
> return
> raise
> if not snippet:
> break
> self.stdout_snippets.append(snippet)

Thanks (and to Grant).  IO seems to be the canonical example.  Where
some languages would force one to write

  c = sys.stdin.read(1)
  while c == ' ':
  c = sys.stdin.read(1)

and an Algol-68 style language would permit one to write

  while (c := read char; c) do skip od

Python opts for

  while True:
 c = sys.stdin.read(1)
 if c != ' ': break

(Forgive the atypical choice of input primitive -- it's for illustrating
the loop style only.)


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

Re: Bigotry and hate speech on the python mailing list

[Ethan Furman]

On 04/17/2017 03:23 PM, Ben Finney wrote:

Paul Rubin writes:

Rurpy writes:



A couple weeks ago a frequent poster here (Steve D'Aprano)
called another participant an "ugly american"


Oh stop trolling.


Paul, that is uncalled for. The charge of bigotry is not to be lightly
dismissed, and we do want to foster an environment here where people
will feel welcome.


You mean all the non-religious people?

Because some of your signatures don't feel welcoming to people of faith:

 \ “I think Western civilization is more enlightened precisely |
  `\ because we have learned how to ignore our religious leaders.” |
_o__)—Bill Maher, 2003 |

 \   “Science shows that belief in God is not only obsolete. It is |
  `\also incoherent.” —Victor J. Stenger, 2001 |
_o__)  |

 \   ?Give a man a fish, and you'll feed him for a day; give him a |
  `\religion, and he'll starve to death while praying for a fish.? |
_o__)   ?Anonymous |

 \   ?Prayer must never be answered: if it is, it ceases to be |
  `\   prayer and becomes correspondence.? ?Oscar Wilde, _The Epigrams |
_o__)of Oscar Wilde_, 1952 |


Steven, please try to be a little more attentive to people's delicate
feefees in the future. Rurpy, should that take care of it?


No, that doesn't do it. Taking care of people's feelings is an essential
part of keeping a community healthy and welcoming, and your belittling
does not help with that.


Neither do (a subset of) your signatures, yet you refuse to filter them out:

[from previous email]

So I will continue to treat all those topics equally: peripheral
comments on beliefs are just part of respectful human discourse, so long
as I'm respectful of the people who may hold such beliefs.


So you're okay with respectfully making people of faith feel unwelcome?

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

Re: Looping [was Re: Python and the need for speed]

[bartc]

On 18/04/2017 01:23, Paul Rubin wrote:

Ben Bacarisse  writes:

  c = sys.stdin.read(1)
  while c == ' ':
  c = sys.stdin.read(1)


c = itertools.dropwhile(
 lambda c: c==' ',
 iter(lambda: sys.stdin.read(1),None)
 ).next()



I tried this but it doesn't like the .next.

I wanted to see if it was any faster or slower than the more obvious loop.

(With the original loop, changing:

c=sys.stdin.read(1)
while c==' ':
c=sys.stdin.read(1)

to:

r=sys.stdin.read

c=r(1)
while c==' ':
c=r(1)

made it 75% faster (reading 10M spaces). Those 3 extra lookups per loop 
I guess (this was run inside a function otherwise the dynamics are 
different).


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

Re: Looping [was Re: Python and the need for speed]

[Ben Bacarisse]

Paul Rubin  writes:

> Ben Bacarisse  writes:
>>   c = sys.stdin.read(1)
>>   while c == ' ':
>>   c = sys.stdin.read(1)

(for the record: I was not suggesting this was how you'd do it but how
you'd be forced to do it in some languages)

> c = itertools.dropwhile(
>  lambda c: c==' ',
>  iter(lambda: sys.stdin.read(1),None)
>  ).next()

Did you mean

  c = next(itertools.dropwhile(lambda c: c==' ',
   iter(lambda: sys.stdin.read(1), None)))

?  I get "AttributeError: 'itertools.dropwhile' object has no attribute
'next'" from your example.

Coming from the lazy language Haskell, I find your example natural
(though the syntax is a little busy for my taste) but would it be
considered Pythonic?

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

Re: Looping [was Re: Python and the need for speed]

[Paul Rubin]

Ben Bacarisse  writes:
> ?  I get "AttributeError: 'itertools.dropwhile' object has no attribute
> 'next'" from your example.

Hmm, .next() worked ok for me in Python 2.7.5.  Not sure what happened.
Maybe something went wrong with my paste.  Oh well.

> Coming from the lazy language Haskell, I find your example natural...

Yep ;)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Buffers and pointers (Py3.4)

[Rob Gaddi]

On 04/17/2017 02:49 PM, eryk sun wrote:

On Mon, Apr 17, 2017 at 5:58 PM, Rob Gaddi
 wrote:

buffertype = c_uint8 * size
return addressof(buffertype.from_buffer(buf, offset))

works but is inefficient and woefully inelegant.


A lot of the cost there is in creating buffertype, but why do you need
that? You can use c_char.from_buffer if all you need is the base
address.

import ctypes

def addressof_buffer(buf):
return ctypes.addressof(ctypes.c_char.from_buffer(buf))

>>> b = bytearray(b'spam')
>>> addressof_buffer(b)
2619159025048
>>> ctypes.string_at(2619159025048, 5)
b'spam\x00'



That's a good catch, that takes some of the stupider part out. 
Performance is still 5x slower, but if I'm really groveling for 200ns 
then I'm either using the wrong language or doing the wrong thing.


In [12]: from ctypes import *
In [13]: ba = bytearray(1024)
In [14]: cta = create_string_buffer(1024)

In [15]: %timeit(c_uint8.from_buffer(ba))
100 loops, best of 3: 252 ns per loop

In [16]: %timeit addressof(c_uint8.from_buffer(ba))
100 loops, best of 3: 284 ns per loop

In [17]: %timeit addressof(cta)
1000 loops, best of 3: 52 ns per loop

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Looping [was Re: Python and the need for speed]

[MRAB]

On 2017-04-18 02:09, Paul Rubin wrote:

Ben Bacarisse  writes:

?  I get "AttributeError: 'itertools.dropwhile' object has no attribute
'next'" from your example.


Hmm, .next() worked ok for me in Python 2.7.5.  Not sure what happened.
Maybe something went wrong with my paste.  Oh well.


Coming from the lazy language Haskell, I find your example natural...


Yep ;)


Your mistake was that you didn't say it was Python 2. :-)

In Python 3 it's:

c = next(itertools.dropwhile(
 lambda c: c==' ',
 iter(lambda: sys.stdin.read(1),None)
 ))
--
https://mail.python.org/mailman/listinfo/python-list

Re: Looping [was Re: Python and the need for speed]

[eryk sun]

On Tue, Apr 18, 2017 at 1:37 AM, MRAB  wrote:
> In Python 3 it's:
>
> c = next(itertools.dropwhile(
>  lambda c: c==' ',
>  iter(lambda: sys.stdin.read(1),None)
>  ))

iter's sentinel should be an empty string.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry and hate speech on the python mailing list

[Wildman via Python-list]

On Tue, 18 Apr 2017 08:23:34 +1000, Ben Finney wrote:

> Paul Rubin  writes:
> 
>> Rurpy  writes:
>> > A couple weeks ago a frequent poster here (Steve D'Aprano
>> > ) called another participant an "ugly
>> > american"
>>
>> Oh stop trolling.
> 
> Paul, that is uncalled for. The charge of bigotry is not to be lightly
> dismissed, and we do want to foster an environment here where people
> will feel welcome.

Your words remind me of this:

"The seriousness of the charge mandates that we investigate
this. Even though there is no evidence, the seriousness of
the charge is what matters."
  --Tom Foley (D) Speaker of the House


-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unable to use Python IDLE after downloading the application

[Terry Reedy]

On 4/17/2017 5:06 PM, ASHISH A wrote:

Hi Team,

I have a 64 bit system with Windows 801 Pro OS. I tried to install Python
3.6.1 from the below link :
https://www.python.org/downloads/

It automatically downloaded that 32 bit Python application and tried to
launch IDLE (32 bit). I could not launch IDLE and it gave me an error
saying DLL file missing (attached snapshot). I have downloaded the DLL file
and also installed Microsoft C++ redistributable 2015.(After following
steps on you-tube to fix such DLL issues).

I am still unable to launch IDLE .


Can you launch python and get a >>> prompt?
If so, can you run `import tkinter`.
Until the answer to both questions is 'yes', leave IDLE out of the 
discussion.


--
Terry Jan Reedy

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

Re: Bigotry and hate speech on the python mailing list

[Rurpy via Python-list]

On 04/17/2017 04:38 AM, Ben Finney wrote:
> Rurpy via Python-list  writes:
> 
>> A couple weeks ago a frequent poster here (Steve D'Aprano
>> ) called another participant an "ugly
>> american" [*1].
> 
> He gave no explicit reference, and so I can see why you would think he
> did what you describe.
> 
> In fact, though, Steven in the message you link to stated:
> 
> If you think that all these people, and hundreds of millions more,
> will just "quietly change the filename" to ASCII because you're too
> lazy, self-centred and arrogant to move on from 1963, then you truly
> are an example of the Ugly American.
> 
> Again, it's not stated explicitly what Steven is referring to, so I can
> see why you would initially be confused.

There is no confusion on my part.  I don't like SJ discussions in technical 
newsgroups any more than you or anyone else here.  I read the relevant posts 
multiple times and thought long and carefully before deciding a response was 
necessary.

> But by now, with plenty of time to look into what was actually being
> discussed, surely you have noticed that Steven was *not* using physical
> appearance as an insult; nor was he using mere national origin as an
> insult.
> 
> Rather, the message is a reference to the Ugly American. Note the
> capitals Steven used; that is how a title is spelled.
> 
> The title “Ugly American” is a reference to a stereotypical *attitude
> and behaviour*, given that name by the 1958 political novel of the same
> name https://en.wikipedia.org/wiki/The_Ugly_American>.

I am and was well aware Mr. D'Aprano's reference was to the book and
derivative stereotype.  I am also aware that book titles are usually 
capitalized.  

(Just as an FYI that you might find useful... I find your response to
be rather condescending in tone.  I have a thick skin and am not easily
offended so no apology necessary but you might want to think about
your communication style sometime.)

> This is not using ugliness, nor American nationality, as an insult. It
> is a reference to objectionable behaviour as Steven described.
>
> Whether you agree that the behaviour described is objectionable, you can
> hopefully agree that naming objectionable behaviour to discourage it, is
> not in itself something to be discouraged.

Both now and in your original apologia for Steven [*1] you fail 
to recognize that there are different ways to point out what one
considers to be objectionable behavior.

Saying that committing crimes is bad, is one thing.  Employing 
the stereotype of African-Americans as criminals and saying that 
one shouldn't act like some black drug-dealing pimp is not. [*2]

> I can fault Steven for assuming that the reader would, by the novel's
> title alone, know of a mid-20th century novel reference or the
> stereotype it describes. That's not a breach of PSF CoC.
> 
> I can fault Steven for assuming that those who *don't* get the reference
> would not leap to the conclusion you've leapt to: that he was using
> national origin as an insult. That assumption on his part is
> unfortunate, and perhaps an apology would be good. Regardless of that,
> it is not a breach of the PSF CoC.

You are focusing here on minor issues, rather like criticizing 
a bank robber for not stopping at a stop sign during his getaway.

And let me repeat what I said above: I leapt to no conclusions; I 
thought carefully before replying.  Your presumption that I am just 
confused because I didn't get his reference is completely off the 
mark.

> What I can't fault him for is using national origin as a verbal weapon.
> He simply did not do that in the message you link to.

He used a stereotype based on national origin to attack someone
whose views he did not agree with.  He subsequently used a different 
stereotype based on age to dispute a view he didn't agree with.
In both cases he could have made his point without dragging in 
millions of other people who he implicitly criticizes on an issue
that is mostly subjective and opinion.

Both are fairly called bigotry as can be demonstrate by transposing 
the statements to other target groups we are more sensitive to
bigotry towards.

Both are in conflict with the PSFs CoC and Diversity statement.
You may nit-pick the words used to describe it, or its importance
but the facts are pretty clear.

>> Further, failure to censure Mr. D'Apano's comments communicates that
>> bigotry is acceptable here which understandably would give pause to
>> members of other groups often subject to bigotry.
> 
> Similarly, my elaboration here – to give it the prominence you rightly
> say that the original sub-thread did not achieve – should demonstrate to
> you that D'Aprano's comments did not constitute bigotry against any
> national origin.
> 
> The charge of bigotry is a strong one here, rightly so, and I think you
> for taking it seriously. Will you drop that charge now? If you won't, I
> think you need to show how this analysis is incorrect.

Some additional thing

Re: Unable to use Python IDLE after downloading the application

[Nathan Ernst]

Off topic, but I find it a little annoying that the default Windows
installer links to the 32-bit installer (and there's no adjacent 64-bit
installer link) - you have to dive into various links to get the 64-bit
installer. Seeing as 64-bit Windows is now the norm, it should be the
default. (It is possible, but creates a larger installer to support both 32
& 64-bit) It'd also be nice if the prerequisites for the installer could be
corrected so we no longer see the "I'm missing X.dll..." emails.

On Mon, Apr 17, 2017 at 9:20 PM, Terry Reedy  wrote:

> On 4/17/2017 5:06 PM, ASHISH A wrote:
>
>> Hi Team,
>>
>> I have a 64 bit system with Windows 801 Pro OS. I tried to install Python
>> 3.6.1 from the below link :
>> https://www.python.org/downloads/
>>
>> It automatically downloaded that 32 bit Python application and tried to
>> launch IDLE (32 bit). I could not launch IDLE and it gave me an error
>> saying DLL file missing (attached snapshot). I have downloaded the DLL
>> file
>> and also installed Microsoft C++ redistributable 2015.(After following
>> steps on you-tube to fix such DLL issues).
>>
>> I am still unable to launch IDLE .
>>
>
> Can you launch python and get a >>> prompt?
> If so, can you run `import tkinter`.
> Until the answer to both questions is 'yes', leave IDLE out of the
> discussion.
>
> --
> Terry Jan Reedy
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bigotry and hate speech on the python mailing list

[Rurpy via Python-list]

On 04/17/2017 08:19 PM, Wildman via Python-list wrote:
> On Tue, 18 Apr 2017 08:23:34 +1000, Ben Finney wrote:
>> Paul Rubin  writes:
>>> Rurpy  writes:
 A couple weeks ago a frequent poster here (Steve D'Aprano
 ) called another participant an "ugly
 american"
>>>
>>> Oh stop trolling.
>>
>> Paul, that is uncalled for. The charge of bigotry is not to be lightly
>> dismissed, and we do want to foster an environment here where people
>> will feel welcome.
> 
> Your words remind me of this:
> 
> "The seriousness of the charge mandates that we investigate
> this. Even though there is no evidence, the seriousness of
> the charge is what matters."
>   --Tom Foley (D) Speaker of the House

Amusing, like Bill Clinton's "depends what your definition
of is is", or Donald Rumsfeld's known unknowns and unknown 
unknowns.  But yet, isn't investigation what produces evidence?
Sometimes things that sound silly at first really aren't.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Looping [was Re: Python and the need for speed]

[Marko Rauhamaa]

Gregory Ewing :

> Marko Rauhamaa wrote:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> Out of curiosity, what proportion of your 'while True' loops are
> infinite? (I.e. no break, return or raise in the loop.)

0%


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

Re: Static typing [was Re: Python and the need for speed]

[Steve D'Aprano]

On Mon, 17 Apr 2017 08:52 pm, Steve D'Aprano wrote:

> but research does continue into using gradual typing for optimizations:
> 
> http://dl.acm.org/citation.cfm?id=2069175

Another interesting research project into speeding up Jython using type
hints:

http://scholar.colorado.edu/ecen_gradetds/57/

and more about gradual typing in Python:

http://homes.soic.indiana.edu/mvitouse/talks/stop12.pdf



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Bigotry and hate speech on the python mailing list

[Rustom Mody]

On Tuesday, April 18, 2017 at 6:18:06 AM UTC+5:30, Ethan Furman wrote:
> On 04/17/2017 03:23 PM, Ben Finney wrote:
> > Paul Rubin writes:
> >> Rurpy writes:
> 
> >>> A couple weeks ago a frequent poster here (Steve D'Aprano)
> >>> called another participant an "ugly american"
> >>
> >> Oh stop trolling.
> >
> > Paul, that is uncalled for. The charge of bigotry is not to be lightly
> > dismissed, and we do want to foster an environment here where people
> > will feel welcome.
> 
> You mean all the non-religious people?
> 
> Because some of your signatures don't feel welcoming to people of faith:
> 
>   \ “I think Western civilization is more enlightened precisely |
>`\ because we have learned how to ignore our religious leaders.” |
> _o__)—Bill Maher, 2003 |
> 
>   \   “Science shows that belief in God is not only obsolete. It is |
>`\also incoherent.” —Victor J. Stenger, 2001 |
> _o__)  |
> 
>   \   ?Give a man a fish, and you'll feed him for a day; give him a |
>`\religion, and he'll starve to death while praying for a fish.? |
> _o__)   ?Anonymous |
> 
>   \   ?Prayer must never be answered: if it is, it ceases to be |
>`\   prayer and becomes correspondence.? ?Oscar Wilde, _The Epigrams |
> _o__)of Oscar Wilde_, 1952 |
> 
> >> Steven, please try to be a little more attentive to people's delicate
> >> feefees in the future. Rurpy, should that take care of it?
> >
> > No, that doesn't do it. Taking care of people's feelings is an essential
> > part of keeping a community healthy and welcoming, and your belittling
> > does not help with that.
> 
> Neither do (a subset of) your signatures, yet you refuse to filter them out:
> 
> [from previous email]
> > So I will continue to treat all those topics equally: peripheral
> > comments on beliefs are just part of respectful human discourse, so long
> > as I'm respectful of the people who may hold such beliefs.
> 
> So you're okay with respectfully making people of faith feel unwelcome?
> 
> --
> ~Ethan~

Thanks Ethan for bullseyeing the problem to the leftie-libbie lie called
'secularism'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Looping [was Re: Python and the need for speed]

[Marko Rauhamaa]

Ben Bacarisse :

> Python opts for
>
>   while True:
>  c = sys.stdin.read(1)
>  if c != ' ': break

I opt for that in C and bash as well.

In fact, when I start writing a loop, I first type:

while True:


Once it is done, I might notice that the loop begins:

while True:
if ...
break

and merge "while" and "if".


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

Re: Bigotry and hate speech on the python mailing list

[Marko Rauhamaa]

Rustom Mody :

> On Tuesday, April 18, 2017 at 6:18:06 AM UTC+5:30, Ethan Furman wrote:
>> You mean all the non-religious people?
>> 
>> Because some of your signatures don't feel welcoming to people of
>> faith:
>
> Thanks Ethan for bullseyeing the problem to the leftie-libbie lie
> called 'secularism'

(You must be trolling, Rustom, but...)

Expressing one's (secular) faith is not bigotry, hate-speech or
harassment. It is questionable whether such expressions have a place in
a technology newsgroup, but the practice is as old as Usenet itself.


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

Re: Looping [was Re: Python and the need for speed]

[breamoreboy]

On Tuesday, April 18, 2017 at 2:09:19 AM UTC+1, Paul Rubin wrote:
> Ben Bacarisse writes:
> > ?  I get "AttributeError: 'itertools.dropwhile' object has no attribute
> > 'next'" from your example.
> 
> Hmm, .next() worked ok for me in Python 2.7.5.  Not sure what happened.
> Maybe something went wrong with my paste.  Oh well.
> 

PEP 3114 -- Renaming iterator.next() to iterator.__next__() 
https://www.python.org/dev/peps/pep-3114/

Kindest regards.

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

Re: Bigotry and hate speech on the python mailing list

[breamoreboy]

On Monday, April 17, 2017 at 10:11:58 AM UTC+1, Rurpy wrote:
> A couple weeks ago a frequent poster here (Steve D'Aprano) called another 
> participant an "ugly american" [*1].  This was followed just a couple weeks 
> later with another post from Mr. D'Aprano attacking a participant as "an old 
> man" who can't understand new technology, a blatant example of ageism [*2].
> 
> The PSF's Diversity statement [*3] explicitly calls out "age" and "national 
> origin" as examples of personal attributes NOT to be used as verbal weapons.  
> It is also neither "considerate" or "respectful" as described in the PSF Code 
> of Conduct [*4] to use national origin or age to attack someone.  In both 
> cases it is reasonable to believe that some Americans or older people will, 
> after reading Mr. D'Aprano's posts, feel uncomfortable posting to this list 
> or responding to Mr. D'Aprano specifically on other issues, because they 
> might well be attacked on the same grounds.  Further, failure to censure Mr. 
> D'Apano's comments communicates that bigotry is acceptable here which 
> understandably would give pause to members of other groups often subject to 
> bigotry.
> 
> I posted a message in objection [*5] that got no response, I would like to 
> think because it got lost in a long thread, not because bigotry is acceptable 
> here and the CoC is just window dressing.
> 
> I also believe the PSF is registered in the US as a tax exempt organization 
> which means it has a legal obligation not to permit discrimination against 
> people based on national origin or age (and other distinctions).
> 
> Would someone from the PSF please publicly clarify exactly why the two cases 
> cited are being treated as acceptable discourse in this list?
> 
> I am not trying to create a controversy for its own sake; when I first 
> started reading this list many years ago I was appalled by rudeness displayed 
> to newcomers coupled with instant anger by the regulars towards non-regulars 
> at the slightest hint of rudeness (even imagined) towards them.  A decade 
> later things have not changed much.  If I posted a remark about "dirty 
> Chinese" (c.f. "ugly American") I would be (justifiably) slammed and likely 
> ejected from the list.  Or if claims that not understanding new tech is a 
> product of age are ok, then why can't I say disparagingly that someone 
> "programs like a girl"?  When a popular poster here says such things, it is 
> not only given a pass, it is actually defended!  
> 
> I am not personally in favor of censorship; the best response to hate speech 
> is a reasoned counter argument IMO.  But if you are going to have a CoC, it 
> must be applied even-handedly.  You cannot apply it when you want to 
> unpopular posters and ignore it when it comes to a one of the clique of 
> regulars.
> 
> 
> [*1] https://mail.python.org/pipermail/python-list/2017-April/720531.html
> [*2] https://mail.python.org/pipermail/python-list/2017-April/721106.html
> [*3] https://www.python.org/community/diversity/
> [*4] https://www.python.org/psf/codeofconduct/
> [*5] https://mail.python.org/pipermail/python-list/2017-April/721135.html

As William Shakespeare put it "Much Ado About Nothing".

Kindest regards.

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

Re: Bigotry and hate speech on the python mailing list

[Ben Finney]

Ethan Furman  writes:

> You mean all the non-religious people?

No, I don't mean that.

> So you're okay with respectfully making people of faith feel
> unwelcome?

No, I'm not okay with that. As I said privately to you, the examples you
cite do not demonstrate disrespect to *people*.

They are disrespectful of *ideas*. Ideas are not inherently worthy of
respect, whether those ideas are religious beliefs, political
affiliation, taste in music, or code indentation style.

People, on the other hand, are inherently worthy of respect. I'm open to
evidence that I make people unwelcome as distinct from the ideas they
hold, and would try to change that.

I won't do it at the expense of treating some ideas, some attitudes, or
some behaviours, as somehow inherently deserving of special treatment.
That would be bigotry.

-- 
 \“Quote me as saying I was mis-quoted.” —Groucho Marx |
  `\   |
_o__)  |
Ben Finney

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

Re: Static typing [was Re: Python and the need for speed]

[Gregory Ewing]

Steve D'Aprano wrote:

I'm not sure why the Cython devs maintain this is not a JIT compiler.
Perhaps I misunderstand something.


A JIT compiler works by observing the actual values taken on
by variables at run time, and if it notices that a particular
variable seems to always have a particular type, it compiles
a special version of the code to handle that type, protected
by appropriate guards.

Cython doesn't do any of that -- it's just a plain, boring,
standard ahead-of-time compiler that goes by the type info
you give it and nothing more.

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

Re: Bigotry and hate speech on the python mailing list

[Ben Finney]

Wildman via Python-list  writes:

> "The seriousness of the charge mandates that we investigate
> this. Even though there is no evidence, the seriousness of
> the charge is what matters."
>   --Tom Foley (D) Speaker of the House

That sounds right to me, provided one reads “there is no evidence” as a
statement about what evidence is present before anyone goes looking for
it (“there is no evidence we are yet aware of”).

In other words: before any evidence exists and before the investigation
is made, it's a mistake to reach any conclusion about the truth of the
charge.

-- 
 \ “I must have a prodigious quantity of mind; it takes me as much |
  `\   as a week sometimes to make it up.” —Mark Twain, _The Innocents |
_o__)  Abroad_ |
Ben Finney

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

Re: Looping [was Re: Python and the need for speed]

[Christian Gollwitzer]

Am 18.04.17 um 02:18 schrieb Ben Bacarisse:


Thanks (and to Grant).  IO seems to be the canonical example.  Where
some languages would force one to write

  c = sys.stdin.read(1)
  while c == ' ':
  c = sys.stdin.read(1)

Python opts for

  while True:
 c = sys.stdin.read(1)
 if c != ' ': break


This loop would be the archetypical do..while or repeat...until to me.

do
c = sys.stdin.read(1)
while c== ' '


-or-

repeat
c  = sys.stdin.read(1)
until c != ' '

is the most clear to me - and in fact this "while True; do something; 
break" thingy is just an idiom to fake a do..while loop in Python.
C does have it, for example, and it is way better like this than the 
abuse of assignment and comma operator in the condition.


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

Re: Looping [was Re: Python and the need for speed]

[Chris Angelico]

On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer  wrote:
> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>
>> Thanks (and to Grant).  IO seems to be the canonical example.  Where
>> some languages would force one to write
>>
>>   c = sys.stdin.read(1)
>>   while c == ' ':
>>   c = sys.stdin.read(1)
>>
>> Python opts for
>>
>>   while True:
>>  c = sys.stdin.read(1)
>>  if c != ' ': break
>
>
> This loop would be the archetypical do..while or repeat...until to me.
>
> do
> c = sys.stdin.read(1)
> while c== ' '
>
>
> -or-
>
> repeat
> c  = sys.stdin.read(1)
> until c != ' '

Except that there's processing code after it.

while True:
c = sys.stdin.read(1)
if not c: break
if c.isprintable(): text += c
elif c == "\x08": text = text[:-1]
# etc

Can you write _that_ as a do-while?

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

Re: Looping [was Re: Python and the need for speed]

[Marko Rauhamaa]

Christian Gollwitzer :

> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>> Python opts for
>>
>>   while True:
>>  c = sys.stdin.read(1)
>>  if c != ' ': break
>
> This loop would be the archetypical do..while or repeat...until to me.
>
> do
>   c = sys.stdin.read(1)
> while c== ' '

No, the code continues. You want to do something with c, right?

> is the most clear to me - and in fact this "while True; do something;
> break" thingy is just an idiom to fake a do..while loop in Python. C
> does have it, for example, and it is way better like this than the
> abuse of assignment and comma operator in the condition.

I do use

   do ... while

in my C code whenever a loop would end in a conditional break. I happens
exceedingly rarely, though.


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