Re: Recommendations for a novice user.

[DL Neil]

Hüseyin,

On 7/01/19 3:35 PM, rbowman wrote:

On 01/02/2019 05:14 AM, Hüseyin Ertuğrul wrote:
I don't know the software language at all. What do you recommend to 
beginners to learn Python.
What should be the working systematic? How much time should I spend 
every day or how much time should I spend on a daily basis.


As much time as you can stand. If you want to make a career of software 
you will be studying for the rest of your life. Get used to it.



That comment is correct. Python has many facets and is used in many 
application-areas - some of which are quite different from any of the 
others. Professionals in each area use Python, but they use the same 
language in quite a different way from others.


To answer your question: it depends a little upon how you learn! Some 
people prefer books, others go to in-person classes.


You might like to check-out Coursera.com for on-line courses. There are 
a couple of ($free) basic Python courses available from U.Mich, 
including one from the venerable "Dr Chuck".


You will also find plenty of web-sites and other organisations offering 
Python training or discussing particular facilities of the language. 
Your search engine is your friend. If you (first) choose one, others 
here may be able to advise you, based upon their personal experience.


Returning to your previous respondent: the ONLY method of learning 
Python is to write Python code - so don't rush any course or reading, 
take the time to prove that you can perform every single step. (even if 
only proving to yourself!)


All the best...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

ANN: Python Meeting Düsseldorf - 09.01.2019

[eGenix Team: M.-A. Lemburg]

[This announcement is in German since it targets a local user group
 meeting in Düsseldorf, Germany]



ANKÜNDIGUNG

  Python Meeting Düsseldorf

   http://pyddf.de/

Ein Treffen von Python Enthusiasten und Interessierten
 in ungezwungener Atmosphäre.

   Mittwoch, 09.01.2019, 18:00 Uhr
   Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
 Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Diese Nachricht ist auch online verfügbar:
https://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2019-01-09


NEUIGKEITEN

 * Bereits angemeldete Vorträge:

   Ulf Morys
"Stack und Unstack mit Pandas Dataframes"

   Detlef Lannert
"Data classes in Python 3.7"

   Charlie Clark
"Using Bitbucket Pipelines for your projects"

   Charlie Clark
"Performance: Doing even more nothing & Cythonize"

   Dominic Geldmacher
"Buchrezension: Data Science Handbook"

   Weitere Vorträge können gerne noch angemeldet werden: i...@pyddf.de

 * Startzeit und Ort:

   Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer
   Arcaden.

   Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und
   befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer
   Arcaden.

   Über dem Eingang steht ein großes "Schwimm' in Bilk" Logo. Hinter
   der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock
   hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus
   dem Aufzug kommt.

   Google Street View: http://bit.ly/11sCfiw



EINLEITUNG

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in
Düsseldorf, die sich an Python Begeisterte aus der Region wendet:

 * http://pyddf.de/

Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal,
auf dem wir die Vorträge nach den Meetings veröffentlichen:

 * http://www.youtube.com/pyddf/

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld,
in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

 * http://www.egenix.com/
 * http://www.clark-consulting.eu/



PROGRAMM

Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning)
Talks und offener Diskussion.

Vorträge können vorher angemeldet werden, oder auch spontan während
des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung
steht zur Verfügung.

(Lightning) Talk Anmeldung bitte formlos per EMail an i...@pyddf.de



KOSTENBETEILIGUNG

Das Python Meeting Düsseldorf wird von Python Nutzern für Python
Nutzer veranstaltet. Um die Kosten zumindest teilweise zu
refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von
EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00
inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.



ANMELDUNG

Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir
bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung
eingegangen. Es erleichtert uns allerdings die Planung.

Meeting Anmeldung bitte formlos per EMail an i...@pyddf.de



WEITERE INFORMATIONEN

Weitere Informationen finden Sie auf der Webseite des Meetings:

http://pyddf.de/

Mit freundlichen Grüßen,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 07 2019)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/


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

Kivy native GUI examples

[Dave]

I need to select a Python GUI.  It needs to cover all of the desktops 
(Linux, Windows, Apple) and hopefully mobile (Android and Ios).  I'm 
looking at Kivy, but have yet to find an example app. that has a native 
looking GUI (Windows, Mac, Linux/Gnome/KDE).  Is that possible and 
anyone know of some examples?


Thanks,
Dave
--
https://mail.python.org/mailman/listinfo/python-list

Re: Kivy native GUI examples

[Thomas Jollans]

On 07/01/2019 15.51, Dave wrote:
> I need to select a Python GUI.  It needs to cover all of the desktops
> (Linux, Windows, Apple) and hopefully mobile (Android and Ios).  I'm
> looking at Kivy, but have yet to find an example app. that has a native
> looking GUI (Windows, Mac, Linux/Gnome/KDE).  Is that possible and
> anyone know of some examples?

AFAIK looking like a native app is quite simply not something Kivy helps
you with. If that's important, you should look into other options such
as Qt (PyQt5 or PySide2).


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

Re: Kivy native GUI examples

[Thomas Jollans]

On 07/01/2019 15.51, Dave wrote:
> I need to select a Python GUI.  It needs to cover all of the desktops
> (Linux, Windows, Apple) and hopefully mobile (Android and Ios).  I'm
> looking at Kivy, but have yet to find an example app. that has a native
> looking GUI (Windows, Mac, Linux/Gnome/KDE).  Is that possible and
> anyone know of some examples?

AFAIK looking like a native app is quite simply not something Kivy helps
you with. If that's important, you should look into other options such
as Qt (PyQt5 or PySide2).


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

Re: Kivy native GUI examples

[Dave]

On 1/7/19 11:14 AM, Thomas Jollans wrote:

On 07/01/2019 15.51, Dave wrote:

I need to select a Python GUI.  It needs to cover all of the desktops
(Linux, Windows, Apple) and hopefully mobile (Android and Ios).  I'm
looking at Kivy, but have yet to find an example app. that has a native
looking GUI (Windows, Mac, Linux/Gnome/KDE).  Is that possible and
anyone know of some examples?


AFAIK looking like a native app is quite simply not something Kivy helps
you with. If that's important, you should look into other options such
as Qt (PyQt5 or PySide2).


-- Thomas



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

Normalizing path strings and separators in cross-platform unit test scripts

[Malcolm Greene]

Any recommendations on normalizing path strings in cross platform
(Windows, Linux, macOS) for unit tests?
Our goal is to normalize path strings to use forward slash separators so
that we can consistently reference path strings in our unit tests in a
cross platform way.
Example: Under Windows we have two paths that are logically the same but fail 
to match for test purposes.
assert str(full_path(f'{test_folder_path}/readonly.txt')) == 'C:/udp-app-
master/dev/tmp/readonly.txt'E   AssertionError: assert 
'C:\\udp-app-...\readonly.txt' == 'C:/udp-app-
ma.../readonly.txt'
Is there a best practice way to convert Windows style paths (with
backslash path separators) to Linux style paths with forward slash path
separators? I've looked at the os and pathlib libraries without seeing
anything that describes our need.
Any downsides to this approach? 

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

Re: Normalizing path strings and separators in cross-platform unit test scripts

[Chris Angelico]

On Tue, Jan 8, 2019 at 5:52 AM Malcolm Greene  wrote:
>
> Any recommendations on normalizing path strings in cross platform
> (Windows, Linux, macOS) for unit tests?
> Our goal is to normalize path strings to use forward slash separators so
> that we can consistently reference path strings in our unit tests in a
> cross platform way.
> Example: Under Windows we have two paths that are logically the same but fail 
> to match for test purposes.
> assert str(full_path(f'{test_folder_path}/readonly.txt')) == 'C:/udp-app-
> master/dev/tmp/readonly.txt'E   AssertionError: assert 
> 'C:\\udp-app-...\readonly.txt' == 'C:/udp-app-
> ma.../readonly.txt'
> Is there a best practice way to convert Windows style paths (with
> backslash path separators) to Linux style paths with forward slash path
> separators? I've looked at the os and pathlib libraries without seeing
> anything that describes our need.
> Any downsides to this approach?

If you are confident you'll never have an actual backslash in a path
name (which would be a requirement if they're cross-platform anyway),
you could just p.replace("\\", "/") to convert them. I don't think
that will break anything on any Windows-based or Unix-based OS (could
be wrong of course).

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

Re: the python name

[DL Neil]

On 7/01/19 9:09 AM, Avi Gross wrote:

[Can we ever change the subject line?]
{REAL SUBJECT: degrees of compilation.}
Peter wrote:

"...
Hoever, this is the Python list and one of the advantages of Python is that we 
don't have to compile our code. So we need a different excuse for fencing on 
office chairs ;-).
..."


You had time for that? We had to move to working on program-B whilst 
awaiting the compile-print-return of program-A - sometimes even 
system/application-B!


In some respects I think the imposed compartmentalisation of one's work 
was a positive aspect. We concentrated on ensuring that solid progress 
was made, run by run - whereas the ease and simplicity of making small 
changes (one after the other) can easily consume tracts of time. (at 
some risk) We would try to foresee problems, and ensure that the code 
would 'continue to work' rather than falling at the first hurdle. On the 
other hand, once the batch was "submitted", we could completely drop 
that program's concerns from our minds. At times a massive stress 
reduction (hence the sword play?), and a good way to approach the next 
task with a constructive (?and less-cluttered) mind.


YMMV!



I won't share my own war stories of how to compile in what now seem primitive 
environments on overloaded machines where you often figured out your mistakes 
on paper before the compiler quit and showed you officially 😊


Ah yes, the ?good, old days when computers were powered by dinosaurs 
running in treadmills...


It wasn't that the machine was overloaded so much, more that the Ops 
staff were charged with 'making efficient use of the machine' - that is 
to say, the 40~45% of CPU time that IBM didn't take to run the OpSys. 
Accordingly, our batch-compile jobs went into a long queue, just so that 
the machine could attend to them when it had some 'spare' capacity.


Since then, Moore's law etc, the economics have changed and the cost of 
programmer time is prioritised over computing costs. This became a 
paradigm-shift for me, because my (?junior) colleagues enacted a 
philosophy of 'throw it at the machine and let the 
real-time/time-sharing mini-computer/PC test it for you' (if only). 
Initially this seemed a scandalous waste of resources, but was also 'the 
way of the future'.


However, with large programs and poor test methods, using the above 
'machine as tester' idea, the costs of running a series of 'long' tests 
with only minor changes between soon exposes economic limits! So, I've 
never quite lost that habit of <>>. That said, the 
tenets of Test-driven development continue to erode my 
conservatism/appeal to my inherent laziness...


Conversely, I have been (admittedly, rather quickly) auditing a Coursera 
MOOC series (Python 3 Programming Specialisation = five courses, out of 
U.Mich). Without commenting on their pedagogical success or otherwise, I 
was struck by their presenting the idea of a 'paper computer'* - even 
having an 'intelligent text book' tool to demonstrate step-wise 
execution of code. (without having to introduce the complexities of a 
debugger) It is a good way to help new-comers understand the 
relationships between a variable's name, its value, its type, its 
mutability, etc, etc - which (IIRC) is where they introduced the idea. 
However, later lessons have included exhortations to review that new 
work, using the 'paper computer' technique.


* apologies: this is the term I learned (all those years ago, mumble, 
mumble) and I'm quite sure they have a different name. The essence is 
the same.


I'm only about 40% through the courses, and will be interested to see if 
they continue to refer to the technique as code-complexity builds...



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

Re: the python name

[DL Neil]

On 7/01/19 2:52 PM, rbowman wrote:

On 01/04/2019 09:34 AM, Avi Gross wrote:
Although I used FORTRAN ages ago and it still seems to be in active 
use, I am not clear on why the name FORMULA TRANSLATOR was chosen. I 
do agree it does sound more like a computer language based on both the 
sound and feel of FORTRAN as well as the expanded version.


It made sense at the time. I first learned FORTRAN in 1965 in 
engineering school. At that time 'computer science' was in its infancy 
and our everyday tool was a slide rule. The computer, an IBM System 
360/30, was seen as another useful tool and engineers should learn to 
translate their formulas into a form acceptable to it. You wrote your 
efforts on coding forms, laboriously transferred those to punch cards, 
and offered your deck up to the priests who fed it to the god visible 
behind plate glass in his air conditioned lair.



Prior to FORTRAN, particularly in the pre-360 IBM mainframe world, the 
only choice was Assembler - a 'language' which was merely a one-to-one 
restatement of machine instructions in an acronym-like form. The issue 
was that every machine type's instruction set was different and 
consequently every Assembly language was different, ie there was no ONE 
Assembler 'language'.


System/360 changed all that. (Brooks's book "The Mythical Man-Month" is 
still a recommended text and a salutary tale) Now we had a series of 
machines, at different sizes (the 360-30 was towards the bottom-end, or 
one of the early sales - depending upon when in the time-line you look), 
but as far as software was concerned, one machine behaved like the next. 
(and IBM very much hoped that we would 'grow' and thus regularly need to 
upgrade the processor - as well as adding peripherals... An IBM salesman 
was not just for Christmas, he was for life!)


This practicality fuelled the (international) standards effort. It 
became possible to have a (single understanding of) FORTRAN (others have 
noted that there were in fact, implementational differences and matters 
of scale), CODASYL went nuts with COBOL, and so-on (Ada anyone?). Also, 
we had manufacturers attempting to impose, um, create a de-facto 
'standard', eg IBM and PL/1 - nothing like the behaviors of today's 
Googles, Microsofts, Apples, etc; of course...


Back to software, languages, and specifically Assembler: every 
computation had to be broken down and coded as individual "low-level" 
instructions:

load 2 into register-A
load 3 into register-B
add register-B into register-A
(note the lack of variable names, also pre-dating the ideas of 
stack-architecture and modern/Intel CPUs!)


After Assembler, FORTRAN 'made all our dreams came true', because we 
were able to write the likes of:

PI = 3.14159
AREA = PI * RADIUS * RADIUS

Can you see the step 'up' to the *formula* part!

Then, we would run our FORTRAN source-code through the *translator* 
(later the generic term became "compiler"). It would translate our code 
into assembler/machine code (varying by machine), saving us from the 
more laborious and pedantic task of expressing ourselves at that level.


Oh the relief!

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

Re: the python name

[DL Neil]

On 7/01/19 3:25 PM, rbowman wrote:

On 01/04/2019 10:45 AM, Peter J. Holzer wrote:

FORTRAN is older than most of us. So it influenced what we think a
computer language should sound like.


Sadly, not for all of us...  FORTRAN seeded later languages with terms 
that are obscure, like rewind().  A blazing powerhouse like the IBM 


Why is that obscure? It makes perfect sense - to those of us who have 
used tape/serial storage! Perhaps less-so to [bobble-heads], sorry I 
mean people who grew-up with 'bubble memory' (Memory sticks, 'flash 
drives', SSDs). In point-of-fact, Python Context Managers


Whilst Python docs and tutorials usually make the opposite point: that 
once a file/context has been read, it is "exhausted" and to continue is 
illogical; don't forget that there is still seek() which does indeed 
enable a "rewind"!


By the same token what thoughts does this sort of code induce?
print( f'The magic number is {result}. So there!' )

Why "print"? I thought I was displaying something on the screen (indeed 
STDIO might go to a file, eg log-like). Whither print?



Reminds me of the person who upon being told to move his mouse to the 
top of the screen, picking-up the device and raised it from the desk 
surface. Made sense to him!



Similarly, one team I joined used Sublime Text for coding. I was happy 
to adapt until I wanted to 'print' my source-code (even though 
"line-flow" stationery is harder to source these days). There is no 
print function in that package!



...

free form input. Prior to that it still assumed you were using Hollerith 
cards. I don't think it ever moved beyond the DO loop.


...and yet PEP-8 and countless 'style guides' maintain the 80 (actually 
72 and 79 to be hob-goblin-ish) which I'm quite sure has nothing to do 
with machine-sizes or relationships to a (single/one, US) dollar bill!



Refs:
https://en.wikipedia.org/wiki/Bobblehead
https://en.wikipedia.org/wiki/Punched_card
https://www.python.org/dev/peps/pep-0008/#maximum-line-length
https://docs.python.org/3.6/tutorial/inputoutput.html

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

System printer object

[Dave]

I need to print to one or both of my system printers.  I have not found 
a printer object in Python or in Tkinter.  This needs to work with 
Linux, Window, and Mac.  Can someone point me in the right direction? 
Ultimately, I want to have a File/Print in the menu that lets me select 
the printer and properties.


Thanks,
Dave
--
https://mail.python.org/mailman/listinfo/python-list

Re: the python name

[MRAB]

On 2019-01-07 23:04, Dennis Lee Bieber wrote:

On Tue, 8 Jan 2019 10:10:13 +1300, DL Neil 
declaimed the following:



Why is that obscure? It makes perfect sense - to those of us who have 
used tape/serial storage! Perhaps less-so to [bobble-heads], sorry I 
mean people who grew-up with 'bubble memory' (Memory sticks, 'flash 
drives', SSDs). In point-of-fact, Python Context Managers



Apologies, but "bubble memory" is something completely different --
using movable magnetic domains rather than capacitive charged bits.

https://en.wikipedia.org/wiki/Bubble_memory



Why "print"? I thought I was displaying something on the screen (indeed 
STDIO might go to a file, eg log-like). Whither print?



Using the wrong language then... COBOL has DISPLAY 

Why "print" -- least surprise! Languages back to FORTRAN (and predating
terminals) had "print" as the quick&dirty output statement (vs the more
complex formatted output). FORTRAN, BASIC, Pascal, probably Modula-2.


[snip]

Pascal has Write and WriteLn, and Modula 2 has variations on Write*, 
such as WriteString and WriteInt.

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

Re: System printer object

[Calvin Spealman]

Neither Python nor Tkinter include interface libraries to talk to hardware
printers out of the box, but a number of libraries and methods exist
depending on your platform. Both Wx and Qt, UI toolkits with great Python
bindings, do support printers to one degree or another, although I don't
know how difficult these are to work with. Either may offer good options,
or at least a starting point, if you look at the wxPython and/or PyQt
libraries.

On Mon, Jan 7, 2019 at 5:20 PM Dave  wrote:

> I need to print to one or both of my system printers.  I have not found
> a printer object in Python or in Tkinter.  This needs to work with
> Linux, Window, and Mac.  Can someone point me in the right direction?
> Ultimately, I want to have a File/Print in the menu that lets me select
> the printer and properties.
>
> Thanks,
> Dave
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspea...@redhat.com  M: +1.336.210.5107

TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Are all items in list the same?

[Bob van der Poel]

I need to see if all the items in my list are the same. I was using set()
for this, but that doesn't work if items are themselves lists. So, assuming
that a is a list of some things, the best I've been able to come up with it:

if a.count( targ ) == len(a):

I'm somewhat afraid that this won't scale all that well. Am I missing
something?
-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are all items in list the same?

[MRAB]

On 2019-01-08 00:14, Bob van der Poel wrote:

I need to see if all the items in my list are the same. I was using set()
for this, but that doesn't work if items are themselves lists. So, assuming
that a is a list of some things, the best I've been able to come up with it:

 if a.count( targ ) == len(a):

I'm somewhat afraid that this won't scale all that well. Am I missing
something?


How about this:

all(item == my_list[0] for item in my_list)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are all items in list the same?

[ike]

You might do something like

if len(a) == 0 or all(i == a[0] for i in a[1:]):

This should be linear complexity and short circuiting and in general it
doesn't get much better than this. Though I wouldn't bet there isn't a
better (faster/clearer/more readable) solution.

On Mon, Jan 07, 2019 at 05:14:14PM -0700, Bob van der Poel wrote:
> I need to see if all the items in my list are the same. I was using set()
> for this, but that doesn't work if items are themselves lists. So, assuming
> that a is a list of some things, the best I've been able to come up with it:
> 
> if a.count( targ ) == len(a):
> 
> I'm somewhat afraid that this won't scale all that well. Am I missing
> something?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Are all items in list the same?

[Cameron Simpson]

On 07Jan2019 17:14, bvdp  wrote:

I need to see if all the items in my list are the same. I was using set()
for this, but that doesn't work if items are themselves lists. So, assuming
that a is a list of some things, the best I've been able to come up with it:

   if a.count( targ ) == len(a):

I'm somewhat afraid that this won't scale all that well. Am I missing
something?


This can be inefficient and probably will be in real life.

For the "true" case (all elements == targ), this is ok - you cannot know 
they are all equal without examining every element.


But it is very inefficient for the false case (not all items == targ) 
because it compares all the items, even if some items have already 
compared unequal. (It compares them all because it must _count_ the 
later equal items, regardless of how many earlier items are unequal).


Because this feels like a homework exercise, we generally offer advice 
and suggestions, thus the nature of the discussion which follows.


The immediate approach is to not use .count and instead just write a 
"for" look which compares each array item in turn, and importantly 
_breaks out of the loop_ as soon as it sees an unequal value. You might 
set a flag (Boolean value) to True, then test the elements: when one is 
unequal, set the flag to False and break from the loop. After the loop, 
the flag will indicate whether all were equal. Give that a try.


_After_ that, once you understand the logic, you could consider the 
built functions Python comes with.


You might look at the builtin "all" function; its help is like this:

   >>> help(all)
   Help on built-in function all in module builtins:

   all(iterable, /)
   Return True if bool(x) is True for all values x in the iterable.

   If the iterable is empty, return True.

It doesn't say so, but it will return as soon as it hits a false item 
from the iterable. So you need to take your list "a" and produce an 
iterable of True or False depending on whether the element is equal to 
your test argument.


The tricky bit is to make "iterable" lazy: an actual iterator which only 
yields values as required. For example, this list comprehension:


 [ elem == targ for elem in a ]

computes the _complete_ list of true/false values and returns a list. So 
passing that to all() does not improve efficiency because for a long 
list it still examines every element even if an early element is 
unequal.


Instead you should look at writing a generator expression or function,
which all() can iterate over: these things only advance as they are 
asked for a value, and so if all() stops early, the generator also does 
not run to completion and so does not uselessly examine the entire list.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Are all items in list the same?

[Tim Chase]

On 2019-01-07 17:14, Bob van der Poel wrote:
> I need to see if all the items in my list are the same. I was using
> set() for this, but that doesn't work if items are themselves
> lists. So, assuming that a is a list of some things, the best I've
> been able to come up with it:
> 
> if a.count( targ ) == len(a):
> 
> I'm somewhat afraid that this won't scale all that well. Am I
> missing something?

Since python2.5 you've had any() and all() functions that make this
pretty tidy and they bail early if proven to not be the case (so if
you have hundreds of thousands of items in the list and you know by
the 2nd one that they're not equal, you don't have to touch hundreds
of thousands of items; just the first two).  So I'd do something like

  def all_equal(iterable):
i = iter(iterable)
first = next(i)
return all(x == first for x in i)

It's undefined for an empty list (well, it throws a StopIteration
but you can special-case that), but should hand the cases with
1 element and 2+ elements (both matching and where any item is not
the same). It should work on an iterator as well but will consume the
items in the process.

And I even like how nicely it reads :-)

-tkc




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

Re: Are all items in list the same?

[Chris Angelico]

On Tue, Jan 8, 2019 at 12:26 PM Tim Chase  wrote:
>   def all_equal(iterable):
> i = iter(iterable)
> first = next(i)
> return all(x == first for x in i)
>
> And I even like how nicely it reads :-)

Yes, there's something beautiful about writing "first = next" :-)

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

Re: Are all items in list the same?

[MRAB]

On 2019-01-08 00:47, i...@koeln.ccc.de wrote:

You might do something like

 if len(a) == 0 or all(i == a[0] for i in a[1:]):

You don't need to check the length of the list because if the list is 
empty, 'all' will return True anyway.



This should be linear complexity and short circuiting and in general it
doesn't get much better than this. Though I wouldn't bet there isn't a
better (faster/clearer/more readable) solution.

On Mon, Jan 07, 2019 at 05:14:14PM -0700, Bob van der Poel wrote:

I need to see if all the items in my list are the same. I was using set()
for this, but that doesn't work if items are themselves lists. So, assuming
that a is a list of some things, the best I've been able to come up with it:

if a.count( targ ) == len(a):

I'm somewhat afraid that this won't scale all that well. Am I missing
something?




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

Re: Are all items in list the same?

[Skip Montanaro]

>
> >  if len(a) == 0 or all(i == a[0] for i in a[1:]):
> >
> You don't need to check the length of the list because if the list is
> empty, 'all' will return True anyway.
>

Given the structure of the expression passed as an argument to all(), won't
you get an IndexError if a is empty without the guard?

(Would try it out if I had an interpreter on my phone...)

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

Re: Are all items in list the same?

[Chris Angelico]

On Tue, Jan 8, 2019 at 1:03 PM Skip Montanaro  wrote:
>
> >
> > >  if len(a) == 0 or all(i == a[0] for i in a[1:]):
> > >
> > You don't need to check the length of the list because if the list is
> > empty, 'all' will return True anyway.
> >
>
> Given the structure of the expression passed as an argument to all(), won't
> you get an IndexError if a is empty without the guard?
>
> (Would try it out if I had an interpreter on my phone...)

No, because the iteration would never happen. If the list is empty,
a[1:] is also empty, and i==a[0] will never be evaluated. So it is
safe. (But I agree that it's not instantly obvious.)

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

SCons Version 3.0.3 Released

[Bill Deegan]

  A new SCons release, 3.0.3, is now available on the SCons download page:

  https://scons.org/pages/download.html


  Here is a summary of the changes since 3.0.1:

  NEW FUNCTIONALITY

- Properly support versioned shared libraries for MacOS.  We've also
introduced two
  new env variables APPLELINK_CURRENT_VERSION and
APPLELINK_COMPATIBILITY_VERSION which will specify
  what is passed to the linkers -current_version and
-compatibility_version flags.  If not specified
  they will be derived from SHLIBVERSION as such:
  - APPLELINK_CURRENT_VERSION = SHLIBVERSION
  - APPLELINK_COMPATIBILITY_VERSION = all but the last digit in
SHLIBVERSION with .0 appended.
  Note that the values of the above will be validated. Valid format
for either APPLELINK variable is
  X[.Y[.Z]] where 0 <= X <= 65535, 0 <= Y <= 255, 0 <= Z <= 255.
- Add flag must_exist to SConscript() call to fail on missing script.
Not failing on missing script is now considered deprecated, and the
first instance will print a
deprecation message.
- Add xz compression format to packaging choices.
- Add Textfile/Substfile to default environment. (issue #3147)
- Added virtualenv support. A new function Virtualenv() determines
whether
SCons runs in a virtualenv. The search PATH may also be extended to
prefer executables from the current virtualenv over the ones
provided by
base environment. New option --enable-virtualenv provided to import
some
virtualenv-related variables to SCons and extend every
env['ENV']['PATH']
automatically. New option --ignore-virtualenv disables this. Two
environment variables, SCONS_ENABLE_VIRTUALENV and
SCONS_IGNORE_VIRTUALENV are supported for the same purpose.

  DEPRECATED FUNCTIONALITY

- Going forward calling SConscript on a non-existing SConscript file
will issue a warning.  Currently
  it will issue a deprecation notice.

  CHANGED/ENHANCED EXISTING FUNCTIONALITY

- Recognize new java 9, 10, 11 (as 9.0 and 10.0, 11.0)

  DOCUMENTATION
- Update some doc examples for Py3: map() now returns an iterable
  instead of a list.

  FIXES

- Fix issue #2980 with credit to Piotr Bartosik (and William Blevins).
This is an issue where using
 TimeStamp-MD5 Decider and CacheDir can yield incorrect md5's being
written into the .sconsign.
 The difference between Piotr Bartosik's patch and the current code
is that the more complicated
 creation of file to csig map is only done when the count of
children for the current node doesn't
 match the previous count which is loaded from the sconsign.


  Thanks to Bernard Blackham, William Deegan, Ray Donnelly, Andrew
Featherstone, Arda Fu,
  Philipp Maierhöfer,  Matthew Marinets, Fredrik Medley, Daniel Moody, Gary
Oberbrunner,
  Jonathon Reinhart, Zachary Tessler, Paweł Tomulik, Richard West, Mats
Wichmann, Bernhard M. Wiedemann,
  and Hao Wu for their contributions to this release.
  Contributors are listed alphabetically by their last name.

git shortlog --no-merges -ns 3.0.1..HEAD
   254  William Deegan
79  Daniel Moody
73  Mats Wichmann
17  Paweł Tomulik
16  Andrew Featherstone
 8  grbd
 7  maiphi
 6  Gary Oberbrunner
 6  Daniel
 4  Hao Wu
 3  Gabriel Russell
 2  MatthewMarinets
 2  Jonathon Reinhart
 2  ArdaFu
 1  Bernhard M. Wiedemann
 1  Isaac Pascual Monells
 1  Fredrik Medley
 1  Philipp Maierhoefer
 1  Piotr Kasprzyk
 1  Ray Donnelly
 1  Zachary Tessler
 1  cclauss
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Normalizing path strings and separators in cross-platform unit test scripts

[eryk sun]

On 1/7/19, Chris Angelico  wrote:
> On Tue, Jan 8, 2019 at 5:52 AM Malcolm Greene  wrote:
>>
>> Is there a best practice way to convert Windows style paths (with
>> backslash path separators) to Linux style paths with forward slash path
>> separators? I've looked at the os and pathlib libraries without seeing
>> anything that describes our need.
>> Any downsides to this approach?

Use os.path.normpath to compare apples to apples, as was mentioned in
another post.

> If you are confident you'll never have an actual backslash in a path
> name (which would be a requirement if they're cross-platform anyway),
> you could just p.replace("\\", "/") to convert them. I don't think
> that will break anything on any Windows-based or Unix-based OS (could
> be wrong of course).

Windows Trivia

The only 'file system' I know of that allows slashes (forward or back)
in names is the named-pipe file system. This is stretching of course
because it's not a general-purpose file system, and in particular it
doesn't support directories.

Some system components and applications create named pipes with
backslash in the name. For example:

>>> print(*sorted(n for n in os.listdir('//./pipe') if '\\' in n), sep='\n')
GoogleCrashServices\S-1-5-18
GoogleCrashServices\S-1-5-18-x64
PIPE_EVENTROOT\CIMV2SCM EVENT PROVIDER
Winsock2\CatalogChangeListener-178-0
Winsock2\CatalogChangeListener-210-0
Winsock2\CatalogChangeListener-214-0
Winsock2\CatalogChangeListener-2a4-0
Winsock2\CatalogChangeListener-2ac-0
Winsock2\CatalogChangeListener-3c0-0
Winsock2\CatalogChangeListener-7fc-0

(The CIMV2SCM pipe is created by the Windows Management
Instrumentation system service. The Winsock pipes are created by
processes that call WSAProviderConfigChange to wait for Winsock
provider configuration changes. The template for the variable suffix
is "-{process_id:x}-{sequence_number}". On this system I also have
pipes created by GoogleCrashHandler[64].exe, which is running as the
SYSTEM account, with SID S-1-5-18.)

A regular '.\\' device path gets normalized to translate forward
slashes to backslashes, so in practice we don't see pipes with forward
slash in the name. To show that's it's possible, we can use a
'?\\' extended device path to prevent normalizing the path. For
example:

>>> h = CreateNamedPipe(r'\\?\pipe\name/with/slashes', 3, 0, 1, 0,
0, 0, None)
>>> print(*(n for n in os.listdir('//./pipe') if '/' in n), sep='\n')
name/with/slashes
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: the python name

[rbowman]

On 01/07/2019 02:10 PM, DL Neil wrote:

Why is that obscure? It makes perfect sense - to those of us who have
used tape/serial storage! Perhaps less-so to [bobble-heads], sorry I
mean people who grew-up with 'bubble memory' (Memory sticks, 'flash
drives', SSDs). In point-of-fact, Python Context Managers


Bubble memory, now there is a blast from the past...
--
https://mail.python.org/mailman/listinfo/python-list

Re: System printer object

[Terry Reedy]

On 1/7/2019 5:17 PM, Dave wrote:
I need to print to one or both of my system printers.  I have not found 
a printer object in Python or in Tkinter.  This needs to work with 
Linux, Window, and Mac.  Can someone point me in the right direction? 
Ultimately, I want to have a File/Print in the menu that lets me select 
the printer and properties.


IDLE can print editor contents to the default printer.  The code is in 
idlelib.iomenu.  The subprocess commands used are


print-command-posix=lpr %%s
print-command-win=start /min notepad /p %%s

I believe %%s becomes the name of the saved file.



--
Terry Jan Reedy


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