Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Rustom Mody wrote:

2. is — machine representation, too fine to be useful


No, it's *not* machine representation. As I pointed out before,
it's part of the abstract semantics of Python.

And it's not "too fine to be useful". On the contrary, being
aware of which objects are the same and which aren't is vital
to writing Python programs that behave in the intended way.


3. graph (or topological) equality



3 captures pythonistas intuition of same better than 1 or 2


I don't think so, see below.


a = [1,2]
b = [a,a]
c = [[1,2],[1,2]]



p = [1,2]
q = [p,p]
r = [[1,2],[1,2]]



Now the pythonista understands that b and c may be math-= but have different 
structure
Whereas b is graph-equal to q
And c is graph-equal to r

However there is no available operation to show/see that distinction


Because usually it's not particularly important to know
whether two separate structures have the same topology.

On the other hand, it *is* important to know things
such as 'b[0] is b[1]' but 'c[0] is not c[1]', because
it makes a difference to what happens if you mutate
any of those.


The trouble is that graph-isomorphism is NP-complete so the crucial operation
cannot be reasonably implemented


We're fortunate that it's not actually a crucial
operation, then. :-)

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

Re: Design: method in class or general function?

[Peter Otten]

leam hall wrote:

> On Thu, Sep 7, 2017 at 8:16 AM, Steve D'Aprano
>  wrote:
> 
>> On Thu, 7 Sep 2017 07:20 pm, Leam Hall wrote:
>>
>> > OOP newbie on Python 2.6.
>>
>> Python 2.6 is ancient, and is missing many nice features. You should
>> consider
>> using the latest version, 3.6.
>>
> 
> I've wrestled with that discussion for a while and Python 3 loses every
> time. There's literally no good reason for me to move to Python 3 earlier
> than mid-2020's. Please accept the fact that there are hundreds of
> thousands of servers, if not millions, running Python 2.x. Whether or not
> Python 3 has any neat cool stuff is irrelevant to those of us seeking to
> use Python to get today's work done.
> 
>> I create instances of Character class with an attribute dict of
>> > 'skills'. The 'skills' dict has the name of a skill as the key and an
>> > int as a value. The code adds or modifies skills before outputting the
>> > Character.
>> >
>> > Is it better design to have a Character.method that takes a 'skill' key
>> > and optional value or to have a general function that takes an
>> > instance, a dict, a key, and an optional value?
>>
>> I'm afraid your example is too generic for me to give an opinion. Do you
>> literally mean a method called "method"? What does it do?
>>
> 
> 
> Using this:
> https://github.com/makhidkarun/py_tools/blob/master/lib/character.py
> 
> Line 19 sets "self.skills" either from the passed in data or from
> https://github.com/makhidkarun/py_tools/blob/master/lib/character_tools.py
> #L34-L48
> 
> So Character.skills is a dict with a string key and an int value. I need
> to be able to add skills and my first attempt is a function:
> https://github.com/makhidkarun/py_tools/blob/master/lib/character_tools.py
> #L52-L56
> 
> Should the "add_skills" function be a method in the character class or be
> made a more generic function to add/modify a key/value pair in a dict that
> is an attribute of an instance? Other tasks will require the add/modify
> functionality but coding that increases complexity. At least for me,
> anyway.
> 
> Sorry about being unclear earlier, coffee was still kicking in and I'm
> still a newbie that mixes up terms.

I'm pleading "method" as it allows per-class implementation. 

Say you use per-career subclasses of a general Character class. There are 
default per-career skill sets, but usually a Character can acquire a skill 
that is not needed in his career -- with the exception that Rogues cannot 
tap dance ;)

Below is a way to implement that with a specialised add_skill() method:

$ cat basic_oo.py
from __future__ import print_function
import random
from collections import defaultdict


class Character(object):
DEFAULT_SKILLS = ['Blade', 'GunCbt', 'Admin', 'Streetwise']

def __init__(self):
self.skills = defaultdict(int)

def add_random_skills(self, terms):
skillnames = self.DEFAULT_SKILLS
for _ in range(2*terms):
self.add_skill(random.choice(skillnames))

def add_skill(self, name, amount=1):
self.skills[name] += amount

def __str__(self):
skills = ", ".join(
"{}={}".format(name, amount)
for name, amount in sorted(self.skills.items())
if amount != 0
)
return "{}({})".format(self.__class__.__name__, skills)


class Rogue(Character):
def add_skill(self, name, amount=1):
if name == "TapDance":
raise ValueError("Sorry, this rogue will never tap dance")
super(Rogue, self).add_skill(name, amount)


class Marine(Character):
DEFAULT_SKILLS = ['GunCbt', 'VaccSuit', 'Leadership', 'Vehicle']


def main():
NUM_CHARACTERS = 5
CHARACTERS = [Marine, Rogue]

characters = [
random.choice(CHARACTERS)() for _ in range(NUM_CHARACTERS)
]

for c in characters:
c.add_random_skills(5)
c.add_skill("RepairBicycles", random.randrange(3))
try:
c.add_skill("TapDance", 3)
except ValueError as err:
print(err)

for c in characters:
print(c)


if __name__ == "__main__":
main()

$ python basic_oo.py 
Sorry, this rogue will never tap dance
Sorry, this rogue will never tap dance
Sorry, this rogue will never tap dance
Rogue(Admin=3, Blade=4, GunCbt=2, Streetwise=1)
Marine(GunCbt=5, Leadership=4, TapDance=3, VaccSuit=1)
Rogue(Blade=3, GunCbt=2, RepairBicycles=2, Streetwise=5)
Rogue(Admin=1, Blade=2, GunCbt=5, RepairBicycles=1, Streetwise=2)
Marine(GunCbt=1, Leadership=3, RepairBicycles=2, TapDance=3, VaccSuit=2,
Vehicle=4)


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

Re: Why do we nned both - __init__() and __new__()

[dieter]

Andrej Viktorovich  writes:

> For my understanding both - __init__() and __new__() works like constructors. 
> And __new__() looks is closer to constructor. __init__() is more for variable 
> initialization. Why I can't just initialize in __init__() ?
>
> class ExampleClass(object):
> def __new__(cls,value):
> print("creating new instance with val %s" % (value,) )
> instance = super(ExampleClass,cls).__new__(cls)
> return instance
> def __init__(self, value):
> print("Initialising instance... with val %s" % (value,))
> self.payload = value
>
> exampleInstance = ExampleClass(42)
> print(exampleInstance.payload)

In this special case (as others already explained, it is quite common),
you do not need "__new__".

In the general case, constructing an object can be split into two
subtasks: obtain a raw piece of storage able to manage the object's state;
initialize the object's state. The first subtask is handled by "__new__",
the second by "__init__".

Python has defaults for both subtasks -- and as others already pointed
out, the default "__new__" is almost always sufficient.

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

My Issues

[Carson McDaniel via Python-list]

Hello, I am an extreme beginner at this so forgive me if I've done something 
simple wrong, but every time I try to open Python (3.6.2), I get an error 
message that says the program can't start because 
api-ms-win-crt-runtime-l1-1-0.dll is missing from my computer. It says to try 
reinstalling the program and I have once and tried repairing it a bunch of time 
but the message still appears. Do I need to download something else and where 
do I find it? 
Thanks for the help,
Carson McDaniel

Sent from my iPhone
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Steve D'Aprano wrote:

A harder question is, what if you take a random number from the Integers? How
many digits will it have in (say) base 10? I don't have a good answer to that.
I think it may be ill-defined.


I think the answer is that on average it has infinitely many
digits -- despite every actual integer only having finitely
many digits!

We can prove this by contradiction. Suppose the answer were
some finite number N. There are only finitely many integers
with N or fewer digits, but there are infinitely many with
more than N digits, so including them in the average must
make it bigger than N. So N cannot be finite.

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

Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Steve D'Aprano wrote:

py> class K: # defines an object
... def __init__(self, x):
... self.x = x
... def append(self, value):
... self.x.append(value)
...
py> a = []
py> b = K(a)
py> a is b  # these are not the same object (they're different types)
False
py> b.append(99)  # but modifying b modifies a
py> a
[99]


You didn't mutate the object bound to b there,
you mutated the one bound to b.x, which is
also bound to a.

All you've shown is that just because a method
is named "append" doesn't mean it mutates the
object it's a method of. :-)

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

Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Rustom Mody wrote:


I'd like to know what these rules are


I can't give you a complete list of them off the top of my
head, but some examples of the kind of rules I have in
mind are:

* After the assigment

   a = b

a and b refer to the same object.

* After

   x = [e1, e2, e3, ...]

x refers to a new object that's not the same as any
other object.

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

class inheritance when not defined

[Andrej Viktorovich]

Hello

I found several class creation samples:

class ExampleClass1:

class ExampleClass2(object):


What is difference between them? Who is the father of ExampleClass1 ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance when not defined

[Thomas Jollans]

On 2017-09-08 10:17, Andrej Viktorovich wrote:
> Hello
> 
> I found several class creation samples:
> 
> class ExampleClass1:
> 
> class ExampleClass2(object):
> 
> 
> What is difference between them? Who is the father of ExampleClass1 ?
> 


In Python 3, unless you've redefined "object", these are the same.

Python 2 had, for historical reasons, a distinction between "old-style"
and "new-style" classes. It normally doesn't matter much, but explicitly
inheriting from object makes a class new-style.


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

Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Rustom Mody wrote:


Models are needed
Math is one possible model
Machines are another


I'm not sure there's any real distinction between "math" and
"machines". A Turing machine, for example, is an idealised
mathematical model of computation.

Maybe the distiction you're trying to get at is "stateless"
vs. "stateful" models of computation? With lambda calculus
being an example of a stateless model, and a Turing machine
a stateful one.

However, I suspect that the reason you're having trouble
with the concept of "same object" in a mathematical setting
is that you're failing to consider the identity of an
object to be a piece of information in its own right that
needs to be included in the model.

If you see something like this from a Python session:

>>> a
[1, 2]
>>> b
[1, 2]

you *can't tell* just by looking at that whether a and
b are bound to the same object. That's an extra piece of
information that isn't shown in those textual representations.

This is why we have things like the "is" operator and
the id() function -- they provide ways of probing that
hidden information.

If you want to model Python computation purely mathematically,
you need to come up with a way to make that extra information
explicit.

There are many ways that can be done. One way is to draw
a graph. Another might be to assign id numbers to objects
and represent objects as (id, value) tuples. But the
information needs to be there in some form, otherwise
you're not modelling Python.

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

Re: class inheritance when not defined

[Ben Finney]

Andrej Viktorovich  writes:

> I found several class creation samples:
>
> class ExampleClass1:
>
> class ExampleClass2(object):
>
>
> What is difference between them?

Very little difference.

In Python 3, both create classes that inherit from one other class,
‘object’.

In Python 2, the first creates ‘ExampleClass1’ that has no parent class,
and doesn't work in the standard type hierarchy. The ‘ExampleClass2’
class inherits from ‘object’ and does participate in the standard type
hierarchy.

This is, broadly, one of the good reasons to abandon Python 2: you can
forget about the special case of classes that don't inherit from
‘object’. In Python 3, they don't exist because every class inherits
ultimately from ‘object’.

> Who is the father of ExampleClass1 ?

No-one, since classes do not have gender. (The convention is to use the
gender-neutral “parent” to refer to that relationship.)

-- 
 \“We cannot solve our problems with the same thinking we used |
  `\   when we created them.” —Albert Einstein |
_o__)  |
Ben Finney

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

Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Marko Rauhamaa wrote:

I definitely trust that:

   a = b
   assert a is b

even when b holds an immutable object.


That's true, but there's rarely a good use case for that
fact that isn't better addressed with an equality comparison
rather than an 'is' test.

As an example, back in the days of string exceptions,
the established idiom was

   MyException = "MyException"

  try:
 ...
 raise MyException
 ...
  except MyException:
 ...

Which worked, but it was error-prone. Writing

   except "MyException":

instead would *probably* work, but wasn't guaranteed.
If the implementation had matched string exceptions
by equality rather than identity, that wouldn't have
been an issue.

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

Re: A question on modification of a list via a function invocation

[Marko Rauhamaa]

Gregory Ewing :

> Marko Rauhamaa wrote:
>> I definitely trust that:
>>
>>a = b
>>assert a is b
>>
>> even when b holds an immutable object.
>
> That's true, but there's rarely a good use case for that
> fact that isn't better addressed with an equality comparison
> rather than an 'is' test.

I use the principle in sentinel objects. I don't care about equality but
identity.

> As an example, back in the days of string exceptions,
> the established idiom was
>
>MyException = "MyException"
>
>   try:
>  ...
>  raise MyException
>  ...
>   except MyException:
>  ...
>
> Which worked, but it was error-prone. Writing
>
>except "MyException":
>
> instead would *probably* work, but wasn't guaranteed.
> If the implementation had matched string exceptions
> by equality rather than identity, that wouldn't have
> been an issue.

I would never have thought of doing that. However, strings are as good
sentinel objects as any (they are trivially printable). Whatever
sentinel object you choose, identity is the name of the game, not
equality.


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

Re: Design: method in class or general function?

[Chris Angelico]

On Thu, Sep 7, 2017 at 11:31 PM, Ben Finney  wrote:
> leam hall  writes:
>
>> I've wrestled with that discussion for a while and Python 3 loses every
>> time.
>
>
> The context of the thread you started was that you are a *newcomer* to
> Python. Now you say you've considered Python 2 versus Python 3 many
> times? What explains that apparent contradiction?

The original comment was "OOP newbie". My reading is that s/he has
used Py2 for years but never actually created a class - which is a
perfectly reasonable thing in Python, unlike some languages.

That said, though: even if you're not going to move to Python 3, I
*strongly* recommend moving to 2.7. Python 2.6 is ancient and not in
support; Python 2.7 is still old, but is in support (for a few more
years with python.org, and then possibly after that if you have
pay-for support eg with Red Hat). There should be very few reasons for
sticking with 2.6.

Those millions of servers running Python 2? You'd be surprised how
many of them are now actually running Python 3 - but the rest of them
NEED to be on 2.7 if they want bug fixes and security patches. Don't
wait for a major problem.

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

Re: Design: method in class or general function?

[Leam Hall]

On 09/08/2017 03:06 AM, Peter Otten wrote:


I'm pleading "method" as it allows per-class implementation.


Peter, as always you are a wealth of information! I have some extra time 
today to digest your notes and visualize tap dancing Marines.


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

Using Python 2 (was: Design: method in class or general function?)

[Leam Hall]

On 09/08/2017 05:45 AM, Chris Angelico wrote:

On Thu, Sep 7, 2017 at 11:31 PM, Ben Finney  wrote:

leam hall  writes:


I've wrestled with that discussion for a while and Python 3 loses every
time.



The context of the thread you started was that you are a *newcomer* to
Python. Now you say you've considered Python 2 versus Python 3 many
times? What explains that apparent contradiction?


The original comment was "OOP newbie". My reading is that s/he has
used Py2 for years but never actually created a class - which is a
perfectly reasonable thing in Python, unlike some languages.

That said, though: even if you're not going to move to Python 3, I
*strongly* recommend moving to 2.7. Python 2.6 is ancient and not in
support; Python 2.7 is still old, but is in support (for a few more
years with python.org, and then possibly after that if you have
pay-for support eg with Red Hat). There should be very few reasons for
sticking with 2.6.

Those millions of servers running Python 2? You'd be surprised how
many of them are now actually running Python 3 - but the rest of them
NEED to be on 2.7 if they want bug fixes and security patches. Don't
wait for a major problem.

ChrisA



Chris, there's a big part of me that agrees with you.

However, those millions of servers are running Python 2.6 and a smaller 
number running 2.7. At least in the US market since Red Hat Enterprise 
Linux and its derivatives run 2.6.6 (RHEL 6) or 2.7.5 (RHEL 7). Not sure 
what Python SuSE uses but they seem to have a fairly large European 
footprint. RHEL 7 goes out the active support door (End of Production 
Phase 3) mid-2024.


I've read comments about Python 3 moving from the Zen of Python. I'm a 
"plain and simple" person myself. Complexity to support what CompSci 
folks want, which was used to describe some of the Python 3 changes, 
doesn't help me get work done.


That said, if the next job I go to is 100% Python 3 then I guess I'm 
doing a lot more Python 3.

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

Re: A question on modification of a list via a function invocation

[Ben Bacarisse]

Steve D'Aprano  writes:

> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote:
>
>> languages without mutable objects don't
>> really care whether they're pass-by-X or pass-by-Y.
>
> Only if you don't care about efficiency.
>
> Believe me, the first time you pass a five gigabyte array to a function using
> pass-by-value, on a machine with only six gigabytes of memory, you'll care.

I think your general idea to separate language semantics from
implementation details is a good one, but you've dropped it here.  A
language with call-by-value semantics need not copy large objects when
passing them to a function.  The program must behave *as if* there is a
copy but there need not actually be one.


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

Re: tictactoe script - commented - may have pedagogical value

[Gregory Ewing]

Steven D'Aprano wrote:
But anyway... it doesn't seem to me that the page is doing any 
computation using HTML. It's more like a book listing a table of primes.


It's a "Choose Your Own Game Of Tic-Tac-Toe" book!

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

Re: Using Python 2

[Ben Finney]

Leam Hall  writes:

> I've read comments about Python 3 moving from the Zen of Python.

For what it's worth: I have done successful conversions of numerous code
bases from Python 2 to Python 3, and that characterisation does not fit
at all. The resulting code base is much more Pythonic.

> I'm a "plain and simple" person myself. Complexity to support what
> CompSci folks want, which was used to describe some of the Python 3
> changes, doesn't help me get work done.

Exactly so. You should ignore the far too academic debates that flourish
here, and concentrate only on the practical differences going from
Python 2 to Python 3. Those alone make it worthwhile to learn Python 3.

-- 
 \  “Life does not cease to be funny when people die any more than |
  `\  it ceases to be serious when people laugh.” —George Bernard Shaw |
_o__)  |
Ben Finney

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

Re: Using Python 2

[Marko Rauhamaa]

Leam Hall :
> However, those millions of servers are running Python 2.6 and a
> smaller number running 2.7. At least in the US market since Red Hat
> Enterprise Linux and its derivatives run 2.6.6 (RHEL 6) or 2.7.5 (RHEL
> 7). Not sure what Python SuSE uses but they seem to have a fairly
> large European footprint. RHEL 7 goes out the active support door (End
> of Production Phase 3) mid-2024.

Ok, the owners of those millions of servers have a problem in their
hands.

What you are saying is that there will be a bonanza next year for Python
2-to-3 consultants. It will also involve a forced upgrade to RHEL 8
(which is nowhere in sight yet).


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

Re: Using Python 2

[Leam Hall]

On 09/08/2017 06:40 AM, Marko Rauhamaa wrote:

Leam Hall :

However, those millions of servers are running Python 2.6 and a
smaller number running 2.7. At least in the US market since Red Hat
Enterprise Linux and its derivatives run 2.6.6 (RHEL 6) or 2.7.5 (RHEL
7). Not sure what Python SuSE uses but they seem to have a fairly
large European footprint. RHEL 7 goes out the active support door (End
of Production Phase 3) mid-2024.


Ok, the owners of those millions of servers have a problem in their
hands.

What you are saying is that there will be a bonanza next year for Python
2-to-3 consultants. It will also involve a forced upgrade to RHEL 8
(which is nowhere in sight yet).


Not really, though a growing market is good. The OS system tools are in 
Python 2 so that's what is installed. Nothing prevents an application 
from installing Python 3, it just can't overwrite the OS python.


Application developers can put Python 3 in /usr/local or can use one of 
the probably older python3 rpm stacks. My dev box has both the OS Python 
2.6.6 and Python 3.6.2 called as python3.



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

Re: A question on modification of a list via a function invocation

[Steve D'Aprano]

On Fri, 8 Sep 2017 05:48 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> A harder question is, what if you take a random number from the Integers? How
>> many digits will it have in (say) base 10? I don't have a good answer to
>> that. I think it may be ill-defined.
> 
> I think the answer is that on average it has infinitely many
> digits -- despite every actual integer only having finitely
> many digits!

I don't think that talking about the average integer is meaningful. Assuming we
are talking about the arithmetic mean, we're dealing with a divergent sum that
depends on the way you do the summation:

0 + 1 + -1 + 2 + -2 + 3 + -3 + ... = 0

0 + 1 + 2 + 3 + 4 + ... + (-1 - 2 - 3 - 4 - ...) = ∞ - ∞ which is undefined.

(Other means have similar problems, they're just harder to write or less
familiar.)

There's even a (legitimate!) argument to be made that the sum of all positive
integers is -1/12.

http://www.slate.com/blogs/bad_astronomy/2014/01/18/follow_up_the_infinite_series_and_the_mind_blowing_result.html

More here:

https://en.wikipedia.org/wiki/1_%2B_2_%2B_3_%2B_4_%2B_%E2%8B%AF

Not to mention the inconvenient fact that we're dividing by infinity:

(sum of all integers (whatever it is!))/∞

I don't think there is any way to select a random integer with equal
probability, but even if we had one, there's no guarantee that the sample means
would converge to the population mean. This is rather like the Cauchy
distribution, where the mean is not defined, and the sample means oscillate
more and more wildly as you sample more values.

So I think that any answer that requires talking about the mean or average is
ill-defined. At least unless we include significantly more rigour than I am
capable of.

If we instead say, "pick a random integer between 0 and N", and then let N
increase without limit, we see that the average number of digits also increases
without limit. But that's not the same as saying that the average number of
digits is infinite!

We *can* say that about choosing a random Real, because the irrational numbers
outnumber the rationals by so much that any random Real we pick is Almost
Always irrational. And irrationals don't have a finite expansion in any integer
base. Hence we can argue that we're almost certain to choose an irrational
number, and irrationals have infinite digits in their expansion.

But we can't say the same thing for integers. As you point out, all integers
have a finite number of digits, so we're on shaky ground to say that the
average integer has infinite digits. That implies that the average is bigger
than all the elements making up the average!

Trying to make sense of divergent series is fraught with traps. Many very simple
sounding questions involving divergent series don't have an answer at all.



-- 
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: Using Python 2 (was: Design: method in class or general function?)

[Chris Angelico]

On Fri, Sep 8, 2017 at 8:12 PM, Leam Hall  wrote:
> However, those millions of servers are running Python 2.6 and a smaller
> number running 2.7. At least in the US market since Red Hat Enterprise Linux
> and its derivatives run 2.6.6 (RHEL 6) or 2.7.5 (RHEL 7). Not sure what
> Python SuSE uses but they seem to have a fairly large European footprint.
> RHEL 7 goes out the active support door (End of Production Phase 3)
> mid-2024.

How many servers are still running RHEL 6 and can't upgrade to RHEL 7
(or later) before 2020? If you absolutely cannot upgrade to Python 3,
at least upgrade to 2.7. But as others have said, upgrading to 3.4+ is
not as hard as many people fear, and your code generally improves as a
result - for example, you often get improvements in
internationalization support from the text/bytes split.

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

python gdal error

[falcone . giuseppe]

Hi to all,

I'm new to python program and I have a problem with the following code.
I'm unable to read field_data variable in retrieve_model_params function.
In debug, execution ends immediately without a message.
Anyone have some idea about that?
If the for cycle in retrieve_model_params is moved to read_data_from_shape 
function, everything works perfectly ...

Thanks a lot.
Giuseppe


import os
from osgeo import ogr

def read_data_from_shape():
"This function load data from a shapefile"

shp_driver = ogr.GetDriverByName("ESRI Shapefile")

data_source = shp_driver.Open("../shape.shp", 0) 

layer = data_source.GetLayer()
feature_count = layer.GetFeatureCount()
print("Number of features:: %d" % (feature_count))
return layer

def retrieve_model_params():

# load data
field_data = read_data_from_shape()

for feature in field_data:
   vol = feature.GetField('VolHa')
   print(vol)

def main():
retrieve_model_params()

if __name__ == '__main__':
main()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A question on modification of a list via a function invocation

[Chris Angelico]

On Fri, Sep 8, 2017 at 10:05 PM, Steve D'Aprano
 wrote:
> On Fri, 8 Sep 2017 05:48 pm, Gregory Ewing wrote:
>
>> Steve D'Aprano wrote:
>>> A harder question is, what if you take a random number from the Integers? 
>>> How
>>> many digits will it have in (say) base 10? I don't have a good answer to
>>> that. I think it may be ill-defined.
>>
>> I think the answer is that on average it has infinitely many
>> digits -- despite every actual integer only having finitely
>> many digits!
>
> I don't think that talking about the average integer is meaningful. Assuming 
> we
> are talking about the arithmetic mean, we're dealing with a divergent sum that
> depends on the way you do the summation:
>
> 0 + 1 + -1 + 2 + -2 + 3 + -3 + ... = 0
>
> 0 + 1 + 2 + 3 + 4 + ... + (-1 - 2 - 3 - 4 - ...) = ∞ - ∞ which is undefined.
>
> (Other means have similar problems, they're just harder to write or less
> familiar.)

Here's a different take on the problem. The first integer (zero) has,
let's say, no digits. Then the next 18 (1 through 9 and -1 through -9)
have one digit. The next 180 have two digits (getting us to 99 and
-99). Etcetera. Multiply each digit count by how many numbers have it,
and divide by the grand total:

(0 * 1 + 1 * 18 + 2 * 18 * 10 + 3 * 18 * 100 ...) / (1 + 18 + 18*10 +
18*100 ...)

As you add terms, the earlier terms become diminishingly significant
to the result, and the final term approaches digits/1.1 (in this
example, 3 * 1800 / (1800+180+18+1)). Since digits is tending towards
+∞, so is the sum.

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

Re: Using Python 2

[Marko Rauhamaa]

Chris Angelico :
> But as others have said, upgrading to 3.4+ is not as hard as many
> people fear, and your code generally improves as a result

That's somewhat irrelevant. Point is, Python 2 will quickly become a
pariah in many corporations during or after 2018, and we are going to
see emergency measures similar to the Y2K craze twenty years ago.

The risk to Python will be whether the occasion is exploited by fanboys
of competing programming languages. The migration from Python 2 might be
to something else than Python 3 in some circles.


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

Re: Using Python 2

[Larry Martell]

On Fri, Sep 8, 2017 at 8:42 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>> But as others have said, upgrading to 3.4+ is not as hard as many
>> people fear, and your code generally improves as a result
>
> That's somewhat irrelevant. Point is, Python 2 will quickly become a
> pariah in many corporations during or after 2018, and we are going to
> see emergency measures similar to the Y2K craze twenty years ago.
>
> The risk to Python will be whether the occasion is exploited by fanboys
> of competing programming languages. The migration from Python 2 might be
> to something else than Python 3 in some circles.

A lot of companies I work for say they don't have the time and/or
money and/or they don't want to risk breaking things. If python 2 ever
is not available I guess then they will have to find the time and
money.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using Python 2

[Chris Angelico]

On Fri, Sep 8, 2017 at 10:42 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>> But as others have said, upgrading to 3.4+ is not as hard as many
>> people fear, and your code generally improves as a result
>
> That's somewhat irrelevant. Point is, Python 2 will quickly become a
> pariah in many corporations during or after 2018, and we are going to
> see emergency measures similar to the Y2K craze twenty years ago.
>
> The risk to Python will be whether the occasion is exploited by fanboys
> of competing programming languages. The migration from Python 2 might be
> to something else than Python 3 in some circles.

And the sky is going to fall on Chicken Little's head, any day now.

Let's see. You can port your code from Python 2.7 to Python 3.6 by
running a script and then checking the results for bytes/text
problems.

You can port your code from Python 2.7 to Ruby by paying developers
big bucks for a good while.

Advantage: Ruby, obviously, because it's easier to change languages
than to audit your code for places where you had lurking bugs that you
didn't know about.

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

Re: A question on modification of a list via a function invocation

[Rhodri James]

On 08/09/17 13:45, Stefan Ram wrote:

Gregory Ewing  writes:
[a random integer will on average have ]

 infinitely many
digits -- despite every actual integer only having finitely
many digits!

   This is not possible because every integer has
   a finite number of digits (in base 10).


Surely an infinitely large integer has an infinite number of digits?

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: A question on modification of a list via a function invocation

[Steve D'Aprano]

On Fri, 8 Sep 2017 05:54 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> py> class K: # defines an object
>> ... def __init__(self, x):
>> ... self.x = x
>> ... def append(self, value):
>> ... self.x.append(value)
>> ...
>> py> a = []
>> py> b = K(a)
>> py> a is b  # these are not the same object (they're different types)
>> False
>> py> b.append(99)  # but modifying b modifies a
>> py> a
>> [99]
> 
> You didn't mutate the object bound to b there,
> you mutated the one bound to b.x, which is
> also bound to a.

Of course I do -- I've mutated one of the parts of the whole, therefore the
whole is mutated too.

Would you argue that if I took a hammer to your computer's motherboard, smashing
it to bits, that I haven't damaged your computer?

My class K is just a minimal sketch of a class that uses dependency injection
and composition, but that's not critical. Any compound object which has
publicly visible mutable parts is subject to the same sort of false positive:

book = Book()
assert book.annotations == []
page = book.pages[15]
assert book is not page  # the whole is not the same as the part
page.annotate(
'Is this the right room for an argument?')  # but if you mutate the part
assert book.annotations == [15]  # the whole mutates too




-- 
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: Using Python 2

[Ned Batchelder]

On 9/8/17 6:12 AM, Leam Hall wrote:
> I've read comments about Python 3 moving from the Zen of Python. I'm a
> "plain and simple" person myself. Complexity to support what CompSci
> folks want, which was used to describe some of the Python 3 changes,
> doesn't help me get work done. 

I've heard a lot of FUD about the Python 3 transition, but this one is
new to me.  What is it that CompSci folks want that developers don't
want, that ruined Python 3?

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

Re: A question on modification of a list via a function invocation

[Antoon Pardon]

Op 08-09-17 om 04:09 schreef Steve D'Aprano:
> On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote:
>
>> On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote:
>>> Rustom Mody wrote:
>>>
 I said: In that case please restate the definition of 'is' from the manual
 which invokes the notion of 'memory' without bringing in memory.
>>> I don't know whether it's in the manual, but at least for
>>> mutable objects, there is a way to define the notion of
>>> "same object" that doesn't require talking about "memory":
>>>
>>> Two names refer to the same object if and only if mutations
>>> made through one are visible through the other.
>> Seems a sensible comment!
>
> Except that it is wrong, or at least over-generalised. It is trivially easy to
> show false positives:
>
> py> class K: # defines an object
> ... def __init__(self, x):
> ... self.x = x
> ... def append(self, value):
> ... self.x.append(value)
> ...
> py> a = []
> py> b = K(a)
> py> a is b  # these are not the same object (they're different types)
> False
> py> b.append(99)  # but modifying b modifies a
> py> a
> [99]

I don't know if this is a False positive. Yes you have shown a mutation
to one that also shows up in the other. But it is possible to mutate b
in ways that doesn't show up in a.

It seems you have interpreted the phrase: "if and only if mutations
made through one are visible through the other." as if it said: 
"if and only if *some* mutations made through one are visible through
the other." while it seems more natural to me to understand it as:
"if and only if *all* mutations made through one are visible through
the other."

So since it is possible to mutate b in ways that are not reflected in
a, I can't really see this as a false positive.

-- 
Antoon Pardon 

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

Re: A question on modification of a list via a function invocation

[Marko Rauhamaa]

r...@zedat.fu-berlin.de (Stefan Ram):

> Marko Rauhamaa  writes:
>>I definitely trust that:
>>a = b
>>assert a is b
>>even when b holds an immutable object.
>
> |Python 3.6.0 ...
> |>>> x = 21568
> |>>> x is 21568
> |False

I wasn't talking about x or 21568. I was talking about a and b.


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

Re: Using Python 2

[Leam Hall]

Various responses in no particular order:

On 09/08/2017 09:57 AM, Ned Batchelder wrote:

I've heard a lot of FUD about the Python 3 transition, but this one is
new to me.  What is it that CompSci folks want that developers don't
want, that ruined Python 3?



It's not FUD if it's true. Calling it FUD without checking is, um, FUD. 
The phrase was "many of the changes in Python 3 are theoretically based, 
cleaning up of how Python does things to make them fit with what 
Computer Science teaches."



On 09/08/2017 08:51 AM, Chris Angelico wrote:
> Let's see. You can port your code from Python 2.7 to Python 3.6 by
> running a script and then checking the results for bytes/text
> problems.

I ran 2to3 on some code that worked under 2.6.6. and 3.6.2. 2to3 broke 
it for both versions and it was a fairly trivial script.




On 09/08/2017 08:42 AM, Marko Rauhamaa wrote:
> That's somewhat irrelevant. Point is, Python 2 will quickly become a
> pariah in many corporations during or after 2018, and we are going to
> see emergency measures similar to the Y2K craze twenty years ago.
>
> The risk to Python will be whether the occasion is exploited by
> fanboys of competing programming languages. The migration from 
Python2 > might be to something else than Python 3 in some circles.


To me this is where the Python community comes in. Moving 3,000 servers 
from RHEL 6 to something that uses Python 3 isn't a trivial task when 
most of those servers are not homogenous HPC nodes.


If Python 2 has bugs that aren't going to be fixed, then let's ask the 
question. If Python 3 was a total re-write that is not backwards 
compatible then it likely has some of the same bugs (due to same coders) 
plus new ones. If Python 3 is not a total re-write then why break 
compatibility?


To say Python 2 is old is true. What does it matter though? Unless 
Python 3 provides a business value for spending lots of time and money 
to change then "old" doesn't matter.


You're right that people may migrate to something besides Python. For me 
that question is real and some of the fuel is how the community can't 
understand that I work on servers that only have an old version of 
python. So far one person has answered the original design question. 
Everyone else has tried to convince me of something that is financially 
and professionally impossible and completely useless.


If you want to encourage people to move from Python 2 to 3 then continue 
to help answer questions when they are Python 2 based. Over time an 
individuals preference will be to move to Python 3 since 90% of the 
skill is already there. From a purely "is python a good language for 
many use cases" perspective the answer is yes. Welcome people and let 
their task needs and passions drive the change.


Leam

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

Re: A question on modification of a list via a function invocation

[Steve D'Aprano]

On Fri, 8 Sep 2017 08:20 pm, Ben Bacarisse wrote:

> Steve D'Aprano  writes:
> 
>> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote:
>>
>>> languages without mutable objects don't
>>> really care whether they're pass-by-X or pass-by-Y.
>>
>> Only if you don't care about efficiency.
>>
>> Believe me, the first time you pass a five gigabyte array to a function using
>> pass-by-value, on a machine with only six gigabytes of memory, you'll care.
> 
> I think your general idea to separate language semantics from
> implementation details is a good one, but you've dropped it here.  A
> language with call-by-value semantics need not copy large objects when
> passing them to a function.  The program must behave *as if* there is a
> copy but there need not actually be one.

You're right: I didn't think of the case where a language simulates
pass-by-value semantics without actually copying. I was thinking only of actual
pass-by-value implementations.

Why would any compiler for a language with immutable arrays actually copy them
when passing them to a function? *shrug* Call it a quality of implementation
issue. Lots of compilers have sub-optimal implementations.

One counter-example might be to implement copy-on-write, in which case the
copying can be delayed until the array is written to. (Although Chris did
specify languages with immutable data structures, so that's out.)

But the larger point that I'm making is that we're not actually doing
computation in some abstract, Platonic space of pure mathematics, we're using
real computers that have to shunt actual electrons through wires and
semiconductors at high speed to do anything. Computation has real costs. We can
try to ignore them, but they exist. And even absent mutation, the way you pass
arguments has costs to:

- the overhead of passing arguments to functions adds up; even a tiny
  difference in efficiency can make a big difference to the overall
  speed of the implementation;

- as well as the memory consumption;

- the amount of work the CPU does, hence your electricity bill;

- to say nothing of the Greenhouse gases, the electronic failure rate, etc;

- let's not forget the complexity of the compiler and the possibility of bugs.

See: https://en.wikipedia.org/wiki/Man_or_boy_test

Unless pass-by-X and pass-by-Y have the same costs, somebody somewhere is going
to care about the difference. That was my point. I tried to express it
humorously rather than pedantically.


-- 
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: Using Python 2

[Chris Angelico]

On Sat, Sep 9, 2017 at 12:23 AM, Leam Hall  wrote:
> Various responses in no particular order:
>
> On 09/08/2017 09:57 AM, Ned Batchelder wrote:
>>
>> I've heard a lot of FUD about the Python 3 transition, but this one is
>> new to me.  What is it that CompSci folks want that developers don't
>> want, that ruined Python 3?
>
> It's not FUD if it's true. Calling it FUD without checking is, um, FUD. The
> phrase was "many of the changes in Python 3 are theoretically based,
> cleaning up of how Python does things to make them fit with what Computer
> Science teaches."

Please give examples. Otherwise it is FUD.

> On 09/08/2017 08:51 AM, Chris Angelico wrote:
>> Let's see. You can port your code from Python 2.7 to Python 3.6 by
>> running a script and then checking the results for bytes/text
>> problems.
>
> I ran 2to3 on some code that worked under 2.6.6. and 3.6.2. 2to3 broke it
> for both versions and it was a fairly trivial script.

Show the code that it broke? I've never seen this, unless it's
something like "now you need to install third-party package X in
Python 3". The 2to3 transformations are fine for everything in the
stdlib.

> On 09/08/2017 08:42 AM, Marko Rauhamaa wrote:
>> That's somewhat irrelevant. Point is, Python 2 will quickly become a
>> pariah in many corporations during or after 2018, and we are going to
>> see emergency measures similar to the Y2K craze twenty years ago.
>>
>> The risk to Python will be whether the occasion is exploited by
>> fanboys of competing programming languages. The migration from Python2 >
>> might be to something else than Python 3 in some circles.
>
> To me this is where the Python community comes in. Moving 3,000 servers from
> RHEL 6 to something that uses Python 3 isn't a trivial task when most of
> those servers are not homogenous HPC nodes.

Of course, but moving ONE server from RHEL 6 to RHEL 7 must surely be
a supported operation. And then moving one more, and one more after
that. The Red Hat folks aren't going to tell you to stay on RHEL 6 for
the rest of time.

> If Python 2 has bugs that aren't going to be fixed, then let's ask the
> question. If Python 3 was a total re-write that is not backwards compatible
> then it likely has some of the same bugs (due to same coders) plus new ones.
> If Python 3 is not a total re-write then why break compatibility?

False dichotomy. It's not a total rewrite, but it fixes certain
long-standing issues. Compatibility had to be broken in order to
change certain behaviours.

> To say Python 2 is old is true. What does it matter though? Unless Python 3
> provides a business value for spending lots of time and money to change then
> "old" doesn't matter.

Of course. And the biggest business value, in a lot of cases, is that
suddenly now your application works for ALL the world's people. A lot
of Python 2 programs, like the equivalents in many other languages,
work fine until someone uses "funny characters". And then their
authors either forbid them, or fiddle around with lots of encoding and
decoding, basically playing whack-a-mole until the problems disappear.
With Python 3, it's completely straight-forward: you know what is
bytes and what is text, and you convert at the boundaries. That's just
one of the advantages of Python 3. A few others, in no particular
order:

* Much better support for asynchronous I/O, allowing higher
per-process throughput for network servers
* Faster Decimal handling
* A much faster way to traverse directory trees
* Several new standard-library modules that do things that formerly
required third-party support

> You're right that people may migrate to something besides Python. For me
> that question is real and some of the fuel is how the community can't
> understand that I work on servers that only have an old version of python.
> So far one person has answered the original design question. Everyone else
> has tried to convince me of something that is financially and professionally
> impossible and completely useless.
>
> If you want to encourage people to move from Python 2 to 3 then continue to
> help answer questions when they are Python 2 based. Over time an individuals
> preference will be to move to Python 3 since 90% of the skill is already
> there. From a purely "is python a good language for many use cases"
> perspective the answer is yes. Welcome people and let their task needs and
> passions drive the change.

If we pretend that Python 3 doesn't exist, how will that encourage
people to move from Py2 to Py3? Be honest now.

Also, be completely honest here: how much work would it take for you
to move your "millions of servers" from Python 2 to, say, PHP? or
Ruby? or C? or JavaScript? Is any of those (or any write-in answer you
wish) actually easier than porting to Python 3?

We've heard the old story of "the Python 3 migration will drive people
away from Python" many, MANY times before. I don't know of any success
stories where someone brags about how easy it was to port their entir

Re: Using Python 2

[Steve D'Aprano]

On Fri, 8 Sep 2017 08:40 pm, Marko Rauhamaa wrote:

> Leam Hall :
>> However, those millions of servers are running Python 2.6 and a
>> smaller number running 2.7. At least in the US market since Red Hat
>> Enterprise Linux and its derivatives run 2.6.6 (RHEL 6) or 2.7.5 (RHEL
>> 7). Not sure what Python SuSE uses but they seem to have a fairly
>> large European footprint. RHEL 7 goes out the active support door (End
>> of Production Phase 3) mid-2024.
> 
> Ok, the owners of those millions of servers have a problem in their
> hands.
> 
> What you are saying is that there will be a bonanza next year for Python
> 2-to-3 consultants. It will also involve a forced upgrade to RHEL 8
> (which is nowhere in sight yet).

Next year is 2018, not 2024. And there's always the possibility of paying Red
Hat for extended support.

(By the way, RHEL 6 goes out of Production Phase 3 in 2020.)



-- 
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: Delay a computation in another thread

[Steve D'Aprano]

On Sun, 3 Sep 2017 03:03 am, MRAB wrote:

> On 2017-09-02 11:59, Steve D'Aprano wrote:
>> On Sat, 2 Sep 2017 08:53 pm, Steve D'Aprano wrote:
>> 
>>> I want to delay a computation and then print it, in the REPL (interactive
>>> interpreter). I have something like this:
>> [...]
>>> The other problem is that if I exit the REPL while a Timer is still active,
>>> it freezes until the time has run before exiting. I know you can't kill a
>>> thread from the main thread, but is there a way for the Timer to see that
>>> the interpreter is shutting down and shut itself down?
>> 
>> Oh! I see Timer objects have a cancel method. So I just need an atexit
>> callback function that calls cancel to each of the Timer threads.
>> 
> Timer is a subclass of Thread, so you can set its .daemon attribute.


Sorry for the long delay in replying to this, but if I set its daemon attribute,
won't that mean it will live on after the interpreter shuts down?

Also, what happens if it tries to print after the interpreter shuts down? Where
does output go?



-- 
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

asyncio.gather cancellation behaviour

[Stephan Houben]

Hi all,

I am a bit mystified about the rationale of the cancellation
behaviour of asyncio.gather. 

  Case 1:
  "If the outer Future is cancelled, all children (that have not completed
  yet) are also cancelled."

  Case 2:
  "If any child is cancelled, this is treated as if it raised
  CancelledError – the outer Future is not cancelled in this case. 
  (THIS IS TO PREVENT THE CANCELLATION OF ONE CHILD TO CAUSE OTHER CHILDREN TO
  BE CANCELLED.)" [capitalization mine]

Indeed I can observe this behavior. However, I would like to further
understand the reasoning for not cancelling in case 2.

Outside asyncio.gather, cancelling an "outer future" does NOT cancel
the "inner future" on which the outer future is currently await-ing, while
cancelling the "inner future" will raise a CancelledError which will
cancel the outer future.

Example:
   
import asyncio

f1 = asyncio.Future()

async def make_f2():
await f1

f2 = asyncio.ensure_future(make_f2())

f2.cancel() # cancelling f1 instead will cancel BOTH f1 and f2

loop = asyncio.get_event_loop()
try:
loop.run_until_complete(f2)
except asyncio.CancelledError:
print("got CancelledError")

print("f1 cancelled: ", f1.cancelled()) # prints False
print("f2 cancelled: ", f2.cancelled()) # prints True

So cancellation "normally" proceeds from inner future -> outer future.

It seems somebody worked hard to reverse the direction in case of
asyncio.gather. Why?

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

Re: Using Python 2

[Ned Batchelder]

On 9/8/17 10:23 AM, Leam Hall wrote:
> On 09/08/2017 09:57 AM, Ned Batchelder wrote:
>> I've heard a lot of FUD about the Python 3 transition, but this one is
>> new to me.  What is it that CompSci folks want that developers don't
>> want, that ruined Python 3?
>
>
> It's not FUD if it's true. Calling it FUD without checking is, um,
> FUD. The phrase was "many of the changes in Python 3 are theoretically
> based, cleaning up of how Python does things to make them fit with
> what Computer Science teaches."

I tried to check, but Google doesn't find me that quote, so I'm not sure
if there was further elaboration. I still don't know which of the Python
3 changes were foisted on us by those bothersome theoretical Computer
Science people.

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

Re: A question on modification of a list via a function invocation

[Steve D'Aprano]

On Fri, 8 Sep 2017 01:01 pm, Rustom Mody wrote:

> On Friday, September 8, 2017 at 7:39:38 AM UTC+5:30, Steve D'Aprano wrote:


>> Rustom, I've already given you the definitive answer to your question about
>> how to define `is` without talking about memory. You haven't replied or
>> acknowledged it, so here is it again:
>> 
>> `is` compares the two operands for identity.
> 
> Preamble… so far so good
> 
>> If the two operands are the same
>> object, `is` returns True, if they are distinct objects, `is` returns False.
> 
> restated
> a is b iff a is b

I hope you are not seriously claiming this is a circular argument.

The first half of your restatement, before the "iff", represents *Python code*,
not natural language, and needs to be quoted[1] to make sense.

If you don't quote it, you are just stating a tautology: a is b iff a is b,
which is true by definition, no matter what meaning we assign to the word "is".

But that's not what I'm saying, and you are wrong to accuse me of giving a
tautology. I'm referring to the Python expression (which is source code in a
programming language which merely looks a bit like English), and explaining it
in English terms.

The "is" in the first half is not the same as the "is" in the second, which
makes the sentence non-circular. This would be more obvious if we were having
this discussion in (say) Hindi, Latin, Swahili, or German:

`A is B` ob und nur wenn A ist B

(Or should that be "ob und nur ob"? Google Translate prefers the first, but I
have my doubts.)

If Python used a mathematical symbol instead of the word "is" as the operator,
it also would obviously be non-circular:

`A ≡ B` if and only if A is B

The mere happenstance that:

(1) Python uses the English word "is" as the operator, rather than some other
symbol like `≡` or `===` or `≣` or `.ist.`; and

(2) we happen to be writing in English, rather than (say) Japanese or Russian or
Esperanto or the Black Speech of Mordor;

does not make my argument circular. You have been lead astray by the mere
contingent fact that Python uses `is` for the operator, instead of some other
symbol.

Don't be fooled: the operator `is` is not the same as the English word "is".

But you know that, so I'm not sure why you are trying to misrepresent my
argument as circular.

So let us start repairing your restatement by adding quotation marks. I use ``
rather than "" because that's the convention used in Markdown for displaying
inline code, and I'm quoting the code:

`a is b` if and only if a is b

is not circular, but it's not very clear[2]. I intentionally avoided using the
English word "is" (not to be confused with the Python operator `is`) in my
explanation, because I knew it would confuse people and lead them astray. So
let us use a better explanation, one which is less likely to give a misleading
impression:

`a is b` if and only if the two operands are the same object

which is closer to what I actually said and avoids giving the mistaken
impression of circular reasoning.

Now if you want to argue about the definition of "same", I have already stated
my position: the commonsense or intuitive meaning of "the same thing" is
sufficient here. If you disagree, then it is up to you to demonstrate a problem
with the commonsense meaning in this context.


>> This does require that we agree on "same object", which as you point out is
>> (in its full generality) a difficult thing to define.
> 
> More than difficult, impossible in the fully abstract philosophical case

Fortunately, the fully abstract philosophical case is irrelevant here.


[...]
> E.g. in the past I've raised
>> the paradox of My Grandfather's Axe.
> 
> Dont see the relevance (here)

The paradox of the axe is one illustration of the difficulty in defining "the
same" in full generality. When objects persist through time and are subject to
change, there are questions raised about what it means to say that something is
the same when all its component bits have been replaced.

So I'm agreeing with you[2] that "the same" in its full generality is difficult
to define in a non-paradoxical way.


>> But the intuitive, common-sense notion of "same object" is, I think,
>> sufficient here. If you want to argue that it is *not* sufficient, I think
>> it's up to you to demonstrate a problem with the definition.
>> 
> 
> Its not that you cant raise philosophical problems if you want
> But when concretized to (basic) math, there are no disputes
> so the argument becomes obtuseness to no point

I'm afraid I have no idea what you think you are saying here.


> In the case of python data model every single interminable thread like this
> one, obviously started by a noob asking something genuinely and indicating
> a real confusion disproves your claim to obvious intuition and common sense

The Original Poster wasn't confused by "sameness". The OP was confusing by
scoping and mutation.

You have to go back to 15 August to find the beginning of the thread, but the OP
was hav

Re: class inheritance when not defined

[Steve D'Aprano]

On Fri, 8 Sep 2017 07:03 pm, Ben Finney wrote:

>> Who is the father of ExampleClass1 ?
> 
> No-one, since classes do not have gender. (The convention is to use the
> gender-neutral “parent” to refer to that relationship.)


Possibly not the case in Russia. Besides, words have gender in many languages.

While I have no problem with correcting people's English when it is relevant,
there's a good way and a bad way to do it.

Good way:

Foreigner speaking English as their second language:
"Who is the father of this class?"

Native English speaker:
"The father is 'object', but in English we would normally 
ask 'what is the parent?' instead."

Bad way:

Foreigner:
"Who is the father of this class?"

Native:
"No one, you ignorant heathen foreigner!"

Worse way:

Foreigner:
"Who is the father of this class?"

Native:
*PLONK*



I'll leave you to guess where I think your response fits in this scale :-)





-- 
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: Need to pass a class instance to a gettext fallback

[Josef Meile]

Hi Peter

Your code worked, but I did some changes. First of all: I decided that I don't 
really needed to pass the py_plugin instance. I only needed an attribute 
called: self._language. Anyway, if I passed it without doing anything else, I 
got:
TypeError: __init__() got an unexpected keyword argument 'language'

In this call inside the MissingTranslationsFallback class.
super(MissingTranslationsFallback, self).__init__(*args, **kwargs)

The error is clear, the constructor of: "gettext.GNUTranslations" isn't 
expecting an argument called: 'language', so, I removed it before doing the 
call:
language = kwargs['language']
del kwargs['language']
super(MissingTranslationsFallback, self).__init__(*args, **kwargs)

And it worked. Thanks a lot for your help. Now it looks nice without those 
nasty global variables :-)

Here the resulting code:
class TranslationService(object):
  """...__init__ and other methods are defined here"""

  def install(self):
"""...some code goes here..."""
current_catalog = gettext.translation(plugin_name, localedir = 
locale_folder,
   class_= 
functools.partial(
   
MissingTranslationsFallback, 
   language 
= self._language
  ),
  languages 
= [current_language]
 )
current_catalog.install()

class MissingTranslationsFallback(gettext.GNUTranslations, object):
  def __init__(self, *args, **kwargs):
language = kwargs['language']
del kwargs['language']
super(MissingTranslationsFallback, self).__init__(*args, **kwargs)
self.add_fallback(MissingTranslationsLogger(language))

Best regards
Josef

-Original Message-
From: Python-list [mailto:python-list-bounces+jmeile=hotmail@python.org] On 
Behalf Of Peter Otten
Sent: Freitag, 8. September 2017 08:15
To: python-list@python.org
Subject: Re: Need to pass a class instance to a gettext fallback

Josef Meile wrote:

> Hi
> 
> I'm working with gettext and need to define a language Fallback. I got 
> this working, but with a global variable. I don't really like this and 
> I would like to pass this variable to the gettext Fallback's 
> contructor, but I don't know how. For simplicity, I won't put the 
> whole code here, just the important parts.
> 
> Before you look at it, I want to ask you: how can I pass the variable:
> "my_plugin" to the constructor of the "MissingTranslationsFallback" class?
> If you see, an instance of this class will be created automatically by 
> gettext. I don't create it. When calling the " add_fallback" method of 
> the gettext.GNUTranslations class, you have to pass a class and not an 
> instance.

Provided the class_ argument to gettext.translation() accepts an arbitrary 
callable the following may work:

import functools

> #Defining a global dict, which is ugly, I know MY_GLOBALS = {}
> 
> class TranslationService(object):
>   """...__init__ and other methods are defined here"""
> 
>   def install(self):
> """...some code goes here..."""
 
 current_catalog = gettext.translation(
 plugin_name, 
 localedir=locale_folder,
 class_=functools.partial(
 MissingTranslationsFallback, 
 py_plugin=self._py_plugin
 ), 
 languages=[current_language]
  )
> current_catalog.install()
> 
> class MissingTranslationsFallback(gettext.GNUTranslations, object):
>   def __init__(self, *args, **kwargs):

  py_plugin = kwargs.pop("py_plugin")

> super(MissingTranslationsFallback, self).__init__(*args, **kwargs)

> i18n_service = py_plugin.get_i18n_service()
> #Adds an instance to the class that will handle the missing
> #translations
> 
self.add_fallback(MissingTranslationsLogger(i18n_service.get_language()))


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

Re: Using Python 2

[Steve D'Aprano]

On Fri, 8 Sep 2017 10:50 pm, Larry Martell wrote:

> If python 2 ever
> is not available I guess then they will have to find the time and
> money.


Python 2 is open source, it will always be available so long as we still have
computers capable of running present day software.

(Presumably by the year 3000 nobody will still be able to run Linux or
Windows... but few companies plan their activities a thousand years in
advance.)

Grab a VM of your OS and Python 2, and you'll be able to run it forever. You
just won't get free support or security upgrades. (And eventually, you won't
even get *paid* support.)

I know of a couple of companies still running Python 1.5 apps. They work,
they're not connected to the Internet, they don't care about bug fixes or
security upgrades, so they have no reason to upgrade.

But they're sure not writing *new* apps in Python 1.5.



-- 
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: Delay a computation in another thread

[Ethan Furman]

On 09/08/2017 07:49 AM, Steve D'Aprano wrote:

On Sun, 3 Sep 2017 03:03 am, MRAB wrote:



Timer is a subclass of Thread, so you can set its .daemon attribute.


Sorry for the long delay in replying to this, but if I set its daemon attribute,
won't that mean it will live on after the interpreter shuts down?


From the docs*:

Note Daemon threads are abruptly stopped at shutdown. Their resources (such as open files, database transactions, etc.) 
may not be released properly. If you want your threads to stop gracefully, make them non-daemonic and use a suitable 
signalling mechanism such as an Event.


--
~Ethan~

* https://docs.python.org/3/library/threading.html

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

Re: Using Python 2

[Steve D'Aprano]

On Fri, 8 Sep 2017 10:51 pm, Chris Angelico wrote:

> On Fri, Sep 8, 2017 at 10:42 PM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>> But as others have said, upgrading to 3.4+ is not as hard as many
>>> people fear, and your code generally improves as a result
>>
>> That's somewhat irrelevant. Point is, Python 2 will quickly become a
>> pariah in many corporations during or after 2018, and we are going to
>> see emergency measures similar to the Y2K craze twenty years ago.
>>
>> The risk to Python will be whether the occasion is exploited by fanboys
>> of competing programming languages. The migration from Python 2 might be
>> to something else than Python 3 in some circles.
> 
> And the sky is going to fall on Chicken Little's head, any day now.
> 
> Let's see. You can port your code from Python 2.7 to Python 3.6 by
> running a script and then checking the results for bytes/text
> problems.
> 
> You can port your code from Python 2.7 to Ruby by paying developers
> big bucks for a good while.
> 
> Advantage: Ruby, obviously, because it's easier to change languages
> than to audit your code for places where you had lurking bugs that you
> didn't know about.


People do irrational things all the time. When faced with the likelihood of a
relatively easy migration from Python 2 to 3, with a small[1] chance of it
blowing out, versus re-implementing the entire app in a completely different
language, we know that a certain percentage of people will swap languages even
if it makes no economic sense. They will underestimate the cost of
re-implementation, and overestimate the risk of a blow-out, because this is
really just an excuse to do what they've wanted to do all along: use a
different language.

Or because somebody in management heard from somebody on LinkedIn that they
heard on Facebook about something they read in some trade magazine about some
company that lost billions porting their Python 2.9 app to Python 3.0 and
besides everyone knows that Python 3 is a failure and Ruby on NodeJS is the new
hot thing that everyone is using.

To be perfectly rational, we *should* consider at least three alternatives:

(1) Stick with Python 2 and pay for support;

(2) Migrate to Python 3;

(3) Re-implement in some other language;

and make a dispassionate choice according to which one has the best cost/benefit
ratio. And that choice won't always be #2.






[1] Depends on the code base, and the developers.


-- 
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: Using Python 2

[Chris Angelico]

On Sat, Sep 9, 2017 at 1:42 AM, Steve D'Aprano
 wrote:
> ... because this is
> really just an excuse to do what they've wanted to do all along: use a
> different language.
>
> Or because somebody in management heard from somebody on LinkedIn that they
> heard on Facebook about something they read in some trade magazine about some
> company that lost billions porting their Python 2.9 app to Python 3.0 and
> besides everyone knows that Python 3 is a failure and Ruby on NodeJS is the 
> new
> hot thing that everyone is using.

Yes, these are two all-too-common reasons. I have to confess that I
dismissed both of them as irrational, but the truth is that they're
both very real-world reasons. I stand corrected.

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

RE: Need to pass a class instance to a gettext fallback

[Peter Otten]

Josef Meile wrote:

> language = kwargs['language']
> del kwargs['language']

Not really important, but there's a method for that:

language = kwargs.pop("language")

>   def __init__(self, *args, **kwargs):
> language = kwargs['language']
> del kwargs['language']

In Python 3 this can also be spelt with a keyword-only language argument:

def __init__(self, *args, language, **kwargs):
...  # no pop() or del 
 


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

Re: Run Windows commands from Python console

[Stephan Houben]

Op 2017-09-06, Rick Johnson schreef :

> One of the nice (current) features of Tkinter menus (that i
> sometimes miss on my windows box!) is the ability to "tear-
> off" a menu cascade and use it as a sort of "pseudo tool
> bar". 

I was under the impression that Tk also supported tear-off
menus under Windows (but not under macOS).
However, many applications apparently explicitly suppress 
this functionality by doing

  Menu(..., tearoff=0)

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

Re: A question on modification of a list via a function invocation

[Steve D'Aprano]

On Fri, 8 Sep 2017 11:01 pm, Rhodri James wrote:

> On 08/09/17 13:45, Stefan Ram wrote:
>> Gregory Ewing  writes:
>> [a random integer will on average have ]
>>>  infinitely many
>>> digits -- despite every actual integer only having finitely
>>> many digits!
>>This is not possible because every integer has
>>a finite number of digits (in base 10).
> 
> Surely an infinitely large integer has an infinite number of digits?

There are no infinitely large integers. All integers are finite.

We can say that there is no largest integer, that they go on forever -- but no
individual integer is infinite.

We soon run out of notation to write them. There are numbers so inconceivably
huge that ordinary exponential notation isn't big enough, like Graham's Number,
and we can invent numbers even bigger:

let G = Graham's Number
let H = G^^G^^G^^ ... ^^G  # tower of a Graham's Number G's, where
^^ is the tetration (double arrow) operator:

x^^y = x^x^x^...^x  # tower of y x's

but even those inconceivably huge numbers are finite.


That's the thing about infinity. No matter how huge the number is, it is still
falls infinitely short of infinite.




-- 
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: Delay a computation in another thread

[Thomas Jollans]

On 2017-09-08 16:49, Steve D'Aprano wrote:
> On Sun, 3 Sep 2017 03:03 am, MRAB wrote:
> 
>> On 2017-09-02 11:59, Steve D'Aprano wrote:
>>> On Sat, 2 Sep 2017 08:53 pm, Steve D'Aprano wrote:
>>>
 I want to delay a computation and then print it, in the REPL (interactive
 interpreter). I have something like this:
>>> [...]
 The other problem is that if I exit the REPL while a Timer is still active,
 it freezes until the time has run before exiting. I know you can't kill a
 thread from the main thread, but is there a way for the Timer to see that
 the interpreter is shutting down and shut itself down?
>>>
>>> Oh! I see Timer objects have a cancel method. So I just need an atexit
>>> callback function that calls cancel to each of the Timer threads.
>>>
>> Timer is a subclass of Thread, so you can set its .daemon attribute.
> 
> 
> Sorry for the long delay in replying to this, but if I set its daemon 
> attribute,
> won't that mean it will live on after the interpreter shuts down?
> 
> Also, what happens if it tries to print after the interpreter shuts down? 
> Where
> does output go?

On Linux, I think it would go to the same virtual terminal as it did
before, if that still exists. (Otherwise, to /dev/null). This is how
processes that started out attached to a terminal and then went into the
background normally behave.

No idea what happens on Windows, but if I had to guess, I'd say "not that".


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

Re: Using Python 2

[Steve D'Aprano]

On Sat, 9 Sep 2017 12:41 am, Chris Angelico wrote:

>> I ran 2to3 on some code that worked under 2.6.6. and 3.6.2. 2to3 broke it
>> for both versions and it was a fairly trivial script.
> 
> Show the code that it broke? I've never seen this, unless it's
> something like "now you need to install third-party package X in
> Python 3". The 2to3 transformations are fine for everything in the
> stdlib.

Chris, I don't think it is controversial that 2to3 occasionally breaks code, or
fails to translate every feature. Even today, there are still the occasional
bug report or feature request for 2to3.

Even human beings can't always translate 2 to 3 flawlessly, and there are some
code bases that actually are tricky to migrate to 3. We shouldn't expect an
automated tool to handle *all* code bases perfectly without human review.

One thing which is notoriously tricky to migrate is mixed bytes/Latin1 text
using Python 2 strings, say you're manipulating file formats that mix text with
binary bytes. These mixed binary/text files are sometimes badly suited to the
new Unicode/bytes model.

(There was some discussion on Python-Ideas about easing the transition. One
concrete change that came out of that was to add % formatting to bytes in 3.5,
but the rest of the discussion seems to have fizzled out due to lack of
interest.)

While 2to3 is still an awesome tool, remember that the core developers have
changed their recommendation from:


# don't do this
write your code in Python 2, and use 2to3 to translate to Python 3, keeping two
code bases;


instead now recommending:

# do this instead
write a single code base that works in both Python 2.7 and Python 3.


>> If you want to encourage people to move from Python 2 to 3 then continue to
>> help answer questions when they are Python 2 based.

We do.

Hell, if somebody wants to ask a question about Python 1.5, I've got a working
copy and can probably answer it!


But some of us can't resist the temptation to evangelise about Python 3 :-)


> Also, be completely honest here: how much work would it take for you
> to move your "millions of servers" from Python 2 to, say, PHP? or
> Ruby? or C? or JavaScript? Is any of those (or any write-in answer you
> wish) actually easier than porting to Python 3?

Maybe not easier, but maybe there's some other payoff:

- some poor, benighted folks just like Javascript or Ruby better than Python
(perhaps they were dropped on the head as babies a few too many times *wink*)

- maybe some companies have a glut of cheap PHP code-monkeys they can throw at a
problem, and shortage of expensive Python rockstars who make unreasonable
demands like "decent working conditions" and "life-work balance";

- perhaps it is worth the increased cost of re-writing your app to get better
performance or reliability (or at least somebody thinks so...)



-- 
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: Using Python 2

[Terry Reedy]

On 9/8/2017 6:12 AM, Leam Hall wrote:


I've read comments about Python 3 moving from the Zen of Python.


Comments about Python 3 range from factual to opinionated to fake.


I'm a "plain and simple" person myself.


Many of the changes in Python3 were simplifications -- removing a 
semi-deprecated 'old way' in favor of a new way that was already in 
Python 2 and widely used.  A major example was dropping old-style 
classes.  This had little impact because by 2.6, people were mostly 
using new-style classes or were mostly using old-style classes in a way 
compatible with new-style classes.



Complexity to support what CompSci folks want,


I was part of the Python 3 design discussions.  I don't remember ever 
hearing anything like "we should do it this more complex way because 
that is what CompSci folks want".


which was used to describe some of the Python 3 changes, 


I presume by people trying to persuade you to avoid Python 3. That does 
not make it true.  This claim is nonsensical in that 3.0 introduced very 
little that was new.  Unicode was added in 2.0, a decade before.


--
Terry Jan Reedy

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

Re: Using Python 2

[Steve D'Aprano]

On Sat, 9 Sep 2017 12:23 am, Leam Hall wrote:

> Various responses in no particular order:
> 
> On 09/08/2017 09:57 AM, Ned Batchelder wrote:
>> I've heard a lot of FUD about the Python 3 transition, but this one is
>> new to me.  What is it that CompSci folks want that developers don't
>> want, that ruined Python 3?
> 
> 
> It's not FUD if it's true. Calling it FUD without checking is, um, FUD.
> The phrase was "many of the changes in Python 3 are theoretically based,
> cleaning up of how Python does things to make them fit with what
> Computer Science teaches."

Such as what?

Got any examples of these changes driven by Comp-Sci theory?


[...]
> If Python 2 has bugs that aren't going to be fixed, 

Eventually, when Python 2.7 is end-of-lifed.

> then let's ask the 
> question. If Python 3 was a total re-write that is not backwards
> compatible then it likely has some of the same bugs (due to same coders)

No, that doesn't follow. For starters, much of the code base is different, so
bugs in one may not exist in the other. Also, Python 3 will continue to get bug
fixes for many years to come, long after 2.7 is end-of-lifed.


> plus new ones. If Python 3 is not a total re-write then why break
> compatibility?

To avoid building up excess cruft in the language.

To fix design mistakes which cannot be fixed without a backwards-incompatible
change.


> To say Python 2 is old is true. What does it matter though? Unless
> Python 3 provides a business value for spending lots of time and money
> to change then "old" doesn't matter.

Indeed you are correct. I know of companies still using Python 1.5.


> If you want to encourage people to move from Python 2 to 3 then continue
> to help answer questions when they are Python 2 based.

As we do. Even if some of us can't help evangelising for Python 3 when they do
so :-)





-- 
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: Using Python 2

[Chris Angelico]

On Sat, Sep 9, 2017 at 2:19 AM, Steve D'Aprano
 wrote:
> On Sat, 9 Sep 2017 12:41 am, Chris Angelico wrote:
>
>>> I ran 2to3 on some code that worked under 2.6.6. and 3.6.2. 2to3 broke it
>>> for both versions and it was a fairly trivial script.
>>
>> Show the code that it broke? I've never seen this, unless it's
>> something like "now you need to install third-party package X in
>> Python 3". The 2to3 transformations are fine for everything in the
>> stdlib.
>
> Chris, I don't think it is controversial that 2to3 occasionally breaks code, 
> or
> fails to translate every feature. Even today, there are still the occasional
> bug report or feature request for 2to3.

For "a fairly trivial script", I would like to see how it breaks it.
The only thing I've seen that frequently causes trouble is the
bytes/text distinction (which, if we're honest, is really just
exposing a problem that was already there), and that's only if you
have a boundary that can't be trivially resolved eg by adding
encoding="utf-8" to your file open calls.

> One thing which is notoriously tricky to migrate is mixed bytes/Latin1 text
> using Python 2 strings, say you're manipulating file formats that mix text 
> with
> binary bytes. These mixed binary/text files are sometimes badly suited to the
> new Unicode/bytes model.

Yes - but I don't expect to see a true mixture of binary and textual
data in "a fairly trivial script". That sort of thing comes up when
you develop parsers for certain network protocols or file formats, but
I don't call those "trivial".

I should have been more clear about my comment there - that it was
specific to the complaint that 2to3 broke a trivial script.

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

Re: Using Python 2

[Grant Edwards]

On 2017-09-08, Steve D'Aprano  wrote:

> One thing which is notoriously tricky to migrate is mixed
> bytes/Latin1 text using Python 2 strings, say you're manipulating
> file formats that mix text with binary bytes. These mixed
> binary/text files are sometimes badly suited to the new
> Unicode/bytes model.

Definitely.  I maintain a lot of apps that do low-level serial and
network protocol stuff, and porting them to 3 is sometimes painful.
The equivalence of text and bytes in 2.7 meant that there was often an
easy, obvious way to do things that can't be readily translated into
Python 3.

Even writing 2/3 compatible code from scratch isn't easy, since the
'bytes' type in 2 is way different than the 'bytes' type in 3.  If
only Python 2 had 'from future import bytes'...

In hindsite, I probably should have sat down years ago and written a
'bytes' class for Python2 that would be compatible with Python3.

-- 
Grant Edwards   grant.b.edwardsYow! Uh-oh!!  I forgot
  at   to submit to COMPULSORY
  gmail.comURINALYSIS!

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

Re: Best way to insert sorted in a list

[logonveera]

On Saturday, June 18, 2011 at 2:23:10 AM UTC+5:30, SherjilOzair wrote:
> There are basically two ways to go about this.
> One is, to append the new value, and then sort the list.
> Another is to traverse the list, and insert the new value at the
> appropriate position.
> 
> The second one's complexity is O(N), while the first one's is O(N *
> log N).
> 
> Still, the second one works much better, because C code is being used
> instead of pythons.
> 
> Still, being a programmer, using the first way (a.insert(x);
> a.sort()), does not feel right.
> 
> What has the community to say about this ? What is the best (fastest)
> way to insert sorted in a list ?

a = []
num = int(input('How many numbers: '))
for n in range(num):
numbers = int(input('Enter values:'))
a.append(numbers)

b = sorted(a)
print(b)
c = int(input("enter value:"))
for i in range(len(b)):
if b[i] > c:
index = i
break
d = b[:i] + [c] + b[i:]
print(d)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to insert sorted in a list

[Steve D'Aprano]

On Sat, 9 Sep 2017 04:39 am, logonve...@gmail.com wrote:

> On Saturday, June 18, 2011 at 2:23:10 AM UTC+5:30, SherjilOzair wrote:
...^^

You're replying to something six years old. Its doubtful the original poster is
still reading.


>> What has the community to say about this ? What is the best (fastest)
>> way to insert sorted in a list ?
> 
> a = []
> num = int(input('How many numbers: '))
> for n in range(num):
> numbers = int(input('Enter values:'))
> a.append(numbers)
> 
> b = sorted(a)
> print(b)
> c = int(input("enter value:"))
> for i in range(len(b)):
> if b[i] > c:
> index = i
> break
> d = b[:i] + [c] + b[i:]
> print(d)

Doing a linear search, followed by slicing and list concatenation, is not likely
to be the fastest method. If you think it is fast, that's because you have only
tested it on small lists. Try a list with (say) a million items.

Probably the best way is to use the bisect module to insert into a sorted list.
Or append to the end, then sort in place. Python's sort is *very* efficient
with almost sorted data.



-- 
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: Using Python 2 (was: Design: method in class or general function?)

[breamoreboy]

On Friday, September 8, 2017 at 11:12:50 AM UTC+1, Leam Hall wrote:
> 
> I've read comments about Python 3 moving from the Zen of Python. I'm a 
> "plain and simple" person myself. Complexity to support what CompSci 
> folks want, which was used to describe some of the Python 3 changes, 
> doesn't help me get work done.
> 

Here https://mail.python.org/pipermail/python-3000/ are the bulk of the 
discussions regarding the move to Python 3.  Which specifics do you disagree 
with and why?

Kindest regards.

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

Re: Using Python 2

[breamoreboy]

On Friday, September 8, 2017 at 5:19:36 PM UTC+1, Steve D'Aprano wrote:
> On Sat, 9 Sep 2017 12:41 am, Chris Angelico wrote:
> 
> >> I ran 2to3 on some code that worked under 2.6.6. and 3.6.2. 2to3 broke it
> >> for both versions and it was a fairly trivial script.
> > 
> > Show the code that it broke? I've never seen this, unless it's
> > something like "now you need to install third-party package X in
> > Python 3". The 2to3 transformations are fine for everything in the
> > stdlib.
> 
> Chris, I don't think it is controversial that 2to3 occasionally breaks code, 
> or
> fails to translate every feature. Even today, there are still the occasional
> bug report or feature request for 2to3.
> 
> Even human beings can't always translate 2 to 3 flawlessly, and there are some
> code bases that actually are tricky to migrate to 3. We shouldn't expect an
> automated tool to handle *all* code bases perfectly without human review.
>

I asked earlier this year why there were still so many 2to3 bug reports 
outstanding.  Regrettably the vast majority are edge cases for which there is 
no  simple solution that will keep everybody happy, so I doubt that they will 
ever get fixed.  I do not believe that to be too important as some of the 
reports are over six years old, so I suspect that workarounds have been found 
with the aid of the MkI eyeball :-)

Kindest regards.

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

Re: Best way to insert sorted in a list

[Stephan Houben]

Op 2017-09-08, logonve...@gmail.com schreef :
> On Saturday, June 18, 2011 at 2:23:10 AM UTC+5:30, SherjilOzair wrote:
>> There are basically two ways to go about this.
>> One is, to append the new value, and then sort the list.
>> Another is to traverse the list, and insert the new value at the
>> appropriate position.
>> 
>> The second one's complexity is O(N), while the first one's is O(N *
>> log N).
>> 
>> Still, the second one works much better, because C code is being used
>> instead of pythons.

Python uses the Timsort ( https://en.wikipedia.org/wiki/Timsort )
algorithm. Timsort is O(N) in the special case of a list of N elements
where the first N-1 are already sorted and the last one is arbitrary.

So appending the value and then calling sort() is in fact O(N) in Python
(hence asymptotically optimal), and also practically fast since the
sort() is implemented in C.

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

Re: Using Python 2

[Stephan Houben]

Op 2017-09-08, Stefan Ram schreef :
>   OTOH, there are those killjoys who complain about
>   "too many parentheses" in programs written in the
>   "simple language".

Which is clearly nonsense since it is easy to show that any working
program in said simple language contains *precisely enough* parentheses.

;-)

(Fortunate that I commented out the unbalanced closing parenthesis.)

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

Merge pdf files using information from two files

[accessnewbie]

I have two files (right now they are spreadsheets but I can export them to any 
format). 

File1 has StoreID (unique) in one column and a pdf map location in the second 
column. (Names not really sequenced numerically)

1 C:/maps/map1.pdf
2 C:/maps/map2.pdf
3 C:/maps/map3.pdf
4 C:/maps/map4.pdf

File2 has 3 columns. Column1 is the County name (unique), Column2 are the store 
IDs that fall in that county separated by commas, and Column3 is warehouse that 
services the store.

County11,2Warehouse1
County21,3Warehouse1
County33  Warehouse4
County42,4Warehouse3

Is it possible to compare both files and append the maps that belong in each 
county and naming it by the county_warehouse.pdf?

Output would be something like this:

C:\maps\final\County1_Warehouse1.pdf (pdf file is map1.pdf and map2.pdf)
C:\maps\final\County2_Warehouse1.pdf (pdf file is map1.pdf and map3.pdf)
C:\maps\final\County3_Warehouse4.pdf (pdf file is map3.pdf)
C:\maps\final\County4_Warehouse1.pdf (pdf file is map2.pdf and map4.pdf)

I could spend some time reorganizing the second file to look like this if it 
makes it easier:

County11Warehouse1
County12Warehouse1
County21Warehouse1
County23Warehouse1
County33Warehouse4
County42Warehouse3
County44Warehouse3

Ideas as to how to accomplish this?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: detaching comprehensions

[Ian Kelly]

On Fri, Sep 8, 2017 at 2:24 PM, Stefan Ram  wrote:
>   Maybe you all know this, but to me this is something new.
>   I learnt it by trial and error in the Python 3.6.0 console.
>
>   Most will know list comprehensions:
>
> |>>> [ i for i in range( 3, 5 )]
> |[3, 4]
>
>   I found out that the comprehension can be detached from the list:
>
> |>>> k =( i for i in range( 3, 5 ))
>
>   but one must use an extra pair of parentheses around it in the
>   assignment.

You don't need an *extra* pair of parentheses per se. The generator
expression simply must be enclosed in parentheses. This is perfectly
valid:

py> sum(i for i in range(3, 5))

>   Now I can insert the "generator" »k« into a function call,
>   but a spread operator should cannot be used there.

If you mean the * syntax, certainly it can.

> |>>> sum( k )
> |7

But you don't want it in this case, because that would do the wrong thing.

>   »sum« expects exactly two arguments, and this is what »k«
>   provides.

Not exactly. sum(k) is only providing the first argument to sum. The
first argument is required to be an iterable, which is what k is. The
second argument, "start", takes its default value of 0. This is
effectively equivalent to calling sum([3, 4]).

sum(*k) on the other hand would spread the values of k over the
arguments of sum and would be equivalent to calling sum(3, 4), which
raises a TypeError because 3 is not iterable.

>   But to insert it again into the place where it was "taken
>   from", a spread operator is required!
>
> |>>> k =( i for i in range( 3, 5 ))
> |>>> [ *k ]
> |[3, 4]

Alternatively:

py> list(k)
[3, 4]

As a final aside, storing a generator in a temporary variable is
usually bad style because it sets up an expectation that the contents
of the variable could be used more than once, when in fact a generator
can only be iterated over once.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: detaching comprehensions

[Peter Otten]

Stefan Ram wrote:

>   Maybe you all know this, but to me this is something new.
>   I learnt it by trial and error in the Python 3.6.0 console.
> 
>   Most will know list comprehensions:
> 
> |>>> [ i for i in range( 3, 5 )]
> |[3, 4]
> 
>   I found out that the comprehension can be detached from the list:
> 
> |>>> k =( i for i in range( 3, 5 ))
> 
>   but one must use an extra pair of parentheses around it in the
>   assignment.

That is called "generator expression". When it does not modify the values 
one usually creates the iterator with k = iter(range(3, 5)).

>   Now I can insert the "generator" »k« into a function call,
>   but a spread operator should cannot be used there.
> 
> |>>> sum( k )
> |7
> 
>   »sum« expects exactly two arguments, and this is what »k«
>   provides.

No. sum() requires one iterable and accepts an optional start value. You are 
passing the iterable only, as may be verified with

 >>> k = (x for x in [["a"], ["b"]])
>>> sum(k)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for +: 'int' and 'list'

versus

>>> k = (x for x in [["a"], ["b"]])
>>> sum(k, [])
['a', 'b']

As with iterators in general once they are exhausted they stay exhausted:

>>> k = (i for i in range(3, 5))
>>> sum(k)
7
>>> sum(k)
0

(you can but shouldn't make your own that doesn't follow that convention)

>   But to insert it again into the place where it was "taken
>   from", a spread operator is required!
> 
> |>>> k =( i for i in range( 3, 5 ))
> |>>> [ *k ]
> |[3, 4]

I have not seen that, I think. The common way is probably

>>> list("foo")
['f', 'o', 'o']

rather than

>>> [*"foo"]
['f', 'o', 'o']

and

>>> tuple("bar")
('b', 'a', 'r')

rather than 

>>> *"bar",
('b', 'a', 'r')

As demonstrated this works with arbitrary iterables, not just generator 
expressions.

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

Re: detaching comprehensions

[bob gailer]

I don't know whether you wanted a reply, since you did not ask for one. 
I am not even sure what your point is. See other comments below.


On 9/8/2017 4:24 PM, Stefan Ram wrote:

   Maybe you all know this, but to me this is something new.
   I learnt it by trial and error in the Python 3.6.0 console.

   Most will know list comprehensions:

|>>> [ i for i in range( 3, 5 )]
|[3, 4]

   I found out that the comprehension can be detached from the list:

|>>> k =( i for i in range( 3, 5 ))

   but one must use an extra pair of parentheses around it in the
   assignment.

   Now I can insert the "generator" »k« into a function call,
   but a spread operator should cannot be used there.

|>>> sum( k )
|7

   »sum« expects exactly two arguments, and this is what »k«
   provides.

Where did you get that idea. If you look at the docs you will see:

"sum(iterable[, start])
Sums start and the items of an iterable from left to right and returns 
the total. start defaults to 0."


sum expects 1 or 2 arguments; when you write sum(k) you are providing 1 
argument.


   But to insert it again into the place where it was "taken
   from", a spread operator is required!

|>>> k =( i for i in range( 3, 5 ))
|>>> [ *k ]
|[3, 4]

"taken from"??
k is a generator object.

Clear?
Bob Gailer
--
https://mail.python.org/mailman/listinfo/python-list

Re: detaching comprehensions

[Ian Kelly]

On Fri, Sep 8, 2017 at 3:03 PM, Peter Otten <__pete...@web.de> wrote:
 *"bar",
> ('b', 'a', 'r')

Now that just makes my eyes hurt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Not appending ("lib") to sys.path breaks tests.

[Leam Hall]

A kind soul pointed out that my code uses a sys.path.append("lib") to 
get files to be imported:


sys.path.append("lib")
from character_tools import *

He noted that having an __init__.py in lib and using:

from .character_tools import *

Should be sufficient for "please don't comment yet about 'import *'" 
levels of sufficient.   :P


The code works under python 2.6.6 and 3.6.2. However, py.test (python 2) 
and pytest (python 3) fails. Besides my usual clue, what am I missing?




### py.test (python 2)
= test session starts 
=

platform linux2 -- Python 2.6.6 -- pytest-2.3.5
collected 0 items / 3 errors

=== ERRORS 

__ ERROR collecting tests/test_base_tools.py 
__

tests/test_base_tools.py:6: in 
>   import lib.base_tools
E   ImportError: No module named lib.base_tools
__ ERROR collecting tests/test_character.py 
___

/usr/lib/python2.6/site-packages/_pytest/python.py:352: in _importtestmodule
>   mod = self.fspath.pyimport(ensuresyspath=True)
/usr/lib/python2.6/site-packages/py/_path/local.py:621: in pyimport
>   __import__(modname)
E File 
"/home/leam/lang/git/makhidkarun/py_tools/tests/test_character.py", line 6

E   import .lib.character
E  ^
E   SyntaxError: invalid syntax
___ ERROR collecting 
tests/test_character_tools.py 

tests/test_character_tools.py:6: in 
>   from ..lib.character_tools import *
E   ValueError: Attempted relative import in non-package
=== 3 error in 0.05 seconds 
===




### pytest (python 3)

= test session starts 
=

platform linux -- Python 3.6.2, pytest-3.2.2, py-1.4.34, pluggy-0.4.0
rootdir: /home/leam/lang/git/makhidkarun/py_tools, inifile:
collected 0 items / 3 errors 



=== ERRORS 

__ ERROR collecting tests/test_base_tools.py 
__
ImportError while importing test module 
'/home/leam/lang/git/makhidkarun/py_tools/tests/test_base_tools.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_base_tools.py:6: in 
import lib.base_tools
E   ModuleNotFoundError: No module named 'lib'
__ ERROR collecting tests/test_character.py 
___
/usr/local/lib/python3.6/site-packages/_pytest/python.py:395: in 
_importtestmodule

mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/local/lib/python3.6/site-packages/py/_path/local.py:662: in pyimport
__import__(modname)
E File 
"/home/leam/lang/git/makhidkarun/py_tools/tests/test_character.py", line 6

E   import .lib.character
E  ^
E   SyntaxError: invalid syntax
___ ERROR collecting 
tests/test_character_tools.py 

tests/test_character_tools.py:6: in 
from ..lib.character_tools import *
E   ValueError: attempted relative import beyond top-level package
!!! Interrupted: 3 errors during collection 
!!!
=== 3 error in 0.22 seconds 
===

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

Re: Delay a computation in another thread

[eryk sun]

On Fri, Sep 8, 2017 at 10:03 AM, Thomas Jollans  wrote:
> On 2017-09-08 16:49, Steve D'Aprano wrote:
>
>> Sorry for the long delay in replying to this, but if I set its daemon 
>> attribute,
>> won't that mean it will live on after the interpreter shuts down?
>>
>> Also, what happens if it tries to print after the interpreter shuts down? 
>> Where
>> does output go?
>
> On Linux, I think it would go to the same virtual terminal as it did
> before, if that still exists. (Otherwise, to /dev/null). This is how
> processes that started out attached to a terminal and then went into the
> background normally behave.

In the normal case, when the interpreter shuts down, the process exits
along with all threads. On the other hand, when Python is embedded,
daemon threads may persist if the interpreter is finalized without
exiting the process. Such threads shouldn't be able to do anything
because they'll block trying to acquire the GIL.

> No idea what happens on Windows, but if I had to guess, I'd say "not that".

The Windows console system (i.e. condrv.sys driver, conhost.exe host,
and csrss.exe session server) doesn't have full support for Unix-style
process groups. They're supported for targeting Ctrl+C and Ctrl+Break.
Also, Ctrl+C is disabled for new process groups. But there's no notion
of foreground and background process groups. Thus it can't implement
the Unix feature that suspends a background process that tries to read
from console input. (Usually background processes in Unix are allowed
to write to the terminal, but that can be disallowed as well.)

In the CMD shell, the closest you can do for running a process in the
background is via "start /b [...] https://mail.python.org/mailman/listinfo/python-list

Re: A question on modification of a list via a function invocation

[Pavol Lisy]

On 9/8/17, Gregory Ewing  wrote:
> Steve D'Aprano wrote:
>> A harder question is, what if you take a random number from the Integers?
>> How
>> many digits will it have in (say) base 10? I don't have a good answer to
>> that.
>> I think it may be ill-defined.
>
> I think the answer is that on average it has infinitely many
> digits -- despite every actual integer only having finitely
> many digits!
>
> We can prove this by contradiction. Suppose the answer were
> some finite number N. There are only finitely many integers
> with N or fewer digits, but there are infinitely many with
> more than N digits, so including them in the average must
> make it bigger than N. So N cannot be finite.

Sorry that my english is so poor that I could only draft ideas. :/

I think that it probably depends on distribution.

Think something like:

def numbers(e=0.999):
''' random numbers from integers '''
while 1:
r = random.random()
yield int(1/(1-r)**e)

and see:
https://www.wolframalpha.com/input/?i=area+between+y+%3D+1%2Fx%5E0.999+and+y+%3D+0+between+x+%3D+0+and+1

and unbounded (for e==1) ->
https://www.wolframalpha.com/input/?i=area+between+y+%3D+1%2Fx+and+y+%3D+0+between+x+%3D+0+and+1

# if somebody likes to test hipothesis ->
def avg(N=1000):
return sum(itertools.islice(numbers(), 0,N,1))/N
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Not appending ("lib") to sys.path breaks tests.

[Ian Kelly]

On Fri, Sep 8, 2017 at 3:18 PM, Leam Hall  wrote:
> A kind soul pointed out that my code uses a sys.path.append("lib") to get
> files to be imported:
>
> sys.path.append("lib")
> from character_tools import *
>
> He noted that having an __init__.py in lib and using:
>
> from .character_tools import *
>
> Should be sufficient for "please don't comment yet about 'import *'" levels
> of sufficient.   :P

I'm confused about where the character_tools import is made. If that's
within a module in the lib package, it should be fine.

> The code works under python 2.6.6 and 3.6.2. However, py.test (python 2) and
> pytest (python 3) fails. Besides my usual clue, what am I missing?
>
>
>
> ### py.test (python 2)
> = test session starts
> =
> platform linux2 -- Python 2.6.6 -- pytest-2.3.5
> collected 0 items / 3 errors
>
> === ERRORS
> 
> __ ERROR collecting tests/test_base_tools.py
> __
> tests/test_base_tools.py:6: in 
>>   import lib.base_tools
> E   ImportError: No module named lib.base_tools

It looks like it's failing to find the lib package. Since you removed
the "lib" directory from sys.path, does its parent directory exist in
sys.path?


> __ ERROR collecting tests/test_character.py
> ___
> /usr/lib/python2.6/site-packages/_pytest/python.py:352: in _importtestmodule
>>   mod = self.fspath.pyimport(ensuresyspath=True)
> /usr/lib/python2.6/site-packages/py/_path/local.py:621: in pyimport
>>   __import__(modname)
> E File
> "/home/leam/lang/git/makhidkarun/py_tools/tests/test_character.py", line 6
> E   import .lib.character
> E  ^
> E   SyntaxError: invalid syntax

Relative imports are only allowed with the "from .foo import bar" syntax.

However if you fix that, I suspect you're then going to run into the
next error below here. I think you actually just want an absolute
import like "import lib.character" here.


> ___ ERROR collecting tests/test_character_tools.py
> 
> tests/test_character_tools.py:6: in 
>>   from ..lib.character_tools import *
> E   ValueError: Attempted relative import in non-package

Packages and directories are not the same thing. This is saying that
the tests directory is not a package, so you can't do a relative
import within it. You probably just want "from lib.character_tools
import *".

The Python 3 errors are the same as the above.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Not appending ("lib") to sys.path breaks tests.

[Leam Hall]

On 09/08/2017 05:41 PM, Ian Kelly wrote:


I'm confused about where the character_tools import is made. If that's
within a module in the lib package, it should be fine.



It looks like it's failing to find the lib package. Since you removed
the "lib" directory from sys.path, does its parent directory exist in
sys.path?


The path is not in the modules path or in sys.path. Hence the append. I 
thought I could add the local "lib" path via "." or "lib.", but it seems 
not.


import lib.character fails in the tests/ directory.



Relative imports are only allowed with the "from .foo import bar" syntax.

However if you fix that, I suspect you're then going to run into the
next error below here. I think you actually just want an absolute
import like "import lib.character" here.





Packages and directories are not the same thing. This is saying that
the tests directory is not a package, so you can't do a relative
import within it. You probably just want "from lib.character_tools
import *".

The Python 3 errors are the same as the above.


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

Merging pdf files based on a value in a field

[accessnewbie]

The StoreID (unique) is in Column1, a pdf map location in Column2, and the file 
name is "Warehouse1" (this will vary). (names not really sequenced numerically)

County1 C:/maps/map1.pdf 
County1 C:/maps/map2.pdf
County2 C:/maps/map1.pdf
County2 C:/maps/map3.pdf
County3 C:/maps/map3.pdf
County4 C:/maps/map2.pdf
County4 C:/maps/map4.pdf

Is it possible to append the pdf maps with the same county and naming the new 
pdf file grouped by the value in the county field and the file name?

Output would be something like this:
C:\maps\final\County1_Warehouse1.pdf (pdf file is map1.pdf and map2.pdf)
C:\maps\final\County2_Warehouse1.pdf (pdf file is map1.pdf and map3.pdf)
C:\maps\final\County3_Warehouse1.pdf (pdf file is map3.pdf)
C:\maps\final\County4_Warehouse1.pdf (pdf file is map2.pdf and map4.pdf)

Right now the data is in a database but I can export this info into any format 
needed.

Ideas as to how to do this?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using Python 2

[Christopher Reimer]

> On Sep 8, 2017, at 6:57 AM, Ned Batchelder  wrote:
> 
> What is it that CompSci folks want that developers don't
> want, that ruined Python 3?

Long-winded debates about obscure language features that left the layman 
programmers in the bit bucket about 50+ comments ago.

While some of this can be informative and enlightening, it can also be a bit  
tedious to read. Just saying...

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

Re: Using Python 2

[leam hall]

On Fri, Sep 8, 2017 at 6:35 PM, Christopher Reimer <
christopher_rei...@icloud.com> wrote:

> > On Sep 8, 2017, at 6:57 AM, Ned Batchelder 
> wrote:
> >
> > What is it that CompSci folks want that developers don't
> > want, that ruined Python 3?
>
> Long-winded debates about obscure language features that left the layman
> programmers in the bit bucket about 50+ comments ago.
>
> While some of this can be informative and enlightening, it can also be a
> bit  tedious to read. Just saying...
>


Chris;  Ned and I have had a great chat off-line. Hopefully the layman
programmers are coming out of the bucket soon.  :)

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

Re: Merge pdf files using information from two files

[Christopher Reimer]

> On Sep 8, 2017, at 1:21 PM, accessnew...@gmail.com wrote:

> Ideas as to how to accomplish this?

Export your spreadsheets as Comma Separated Values (CSV) files and use the CSV 
module to read/write those files.

https://docs.python.org/3/library/csv.html

Chris R. 

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

Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Steve D'Aprano wrote:


I don't think that talking about the average integer is meaningful.


We're not averaging the integers, we're averaging their numbers
of digits, which are natural numbers.

To do this rigorously you could write down an expression for
the average length of integers up to some finite N, and then
take the limit as N -> infinity. I haven't worked through
that, but I'd expect the sum to diverge.

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

Re: A question on modification of a list via a function invocation

[Gregory Ewing]

Steve D'Aprano wrote:

The paradox of the axe is one illustration of the difficulty in defining "the
same" in full generality.


The axe situation doesn't arise in Python, because "same
object" in Python is a concept that only applies to objects
existing at the same time.

There's no way to even ask a question like "does a refer
to the same object that b did a second ago", because
the only way to test object identity is to use the
'is' operator, which takes two expressions evaluated
at the same time.

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

Merging pdf files based on a value in a field

[MrJean1]

Try PyPDF2, see the merge example.



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

Re: class inheritance when not defined

[Ben Finney]

Steve D'Aprano  writes:

> Good way:
>
> Foreigner speaking English as their second language:
> "Who is the father of this class?"
>
> Native English speaker:
> "The father is 'object', but in English we would normally ask
> 'what is the parent?' instead."

Of the three scenarios you presented, this is clearly the closest. I
gave the correct answer, I offered a correction to English usage, and I
gave no insult to the questioner.

-- 
 \   “Nothing exists except atoms and empty space; everything else |
  `\  is opinion.” —Democritus |
_o__)  |
Ben Finney

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

Re: Why do we nned both - __init__() and __new__()

[Gregory Ewing]

dieter wrote:

In the general case, constructing an object can be split into two
subtasks: obtain a raw piece of storage able to manage the object's state;
initialize the object's state. The first subtask is handled by "__new__",
the second by "__init__".


Except that's not quite correct, because the cases where
you need to override __new__ are ones where it does *more*
than just allocate storage.

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

Re: A question on modification of a list via a function invocation

[Steve D'Aprano]

On Sat, 9 Sep 2017 10:34 am, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> The paradox of the axe is one illustration of the difficulty in defining "the
>> same" in full generality.
> 
> The axe situation doesn't arise in Python, because "same
> object" in Python is a concept that only applies to objects
> existing at the same time.

Indeed. That's why in an earlier post I mentioned that it wasn't relevant to the
question of `is`. I only mentioned it again because Rustom claimed to not
understand why I mentioned it. I mentioned it because I was *agreeing with him*
about the notion of sameness being hard to define vigorously in FULL
GENERALITY.

Which is irrelevant to the question of "same object". Either the paradoxes
of "sameness" don't apply to Python objects, in which the paradoxes don't
matter, or they apply to everything, in which case we're stuck with them and
shouldn't let them prevent us using the common sense meaning of "same object"
when discussing Python `is`.


> There's no way to even ask a question like "does a refer
> to the same object that b did a second ago", because
> the only way to test object identity is to use the
> 'is' operator, which takes two expressions evaluated
> at the same time.

I wouldn't quite go that far. We could, for example, record the ID, type, and
some representation of the object (repr? str?), and compare them to those of
the existing object. If any of them differ, then we know they aren't (weren't?)
the same object. If all three are the same, we cannot draw any conclusions.


"Is this list I have now identical to the tuple I had five minutes ago?"

"Obviously not, because lists aren't tuples."

But apart from tricks like that, I agree: objects that existed in the past but
no longer exist don't have a meaningful identity in Python.



-- 
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

Questions.

[V Vishwanathan]

Hi, From what I see in the recent 4/5 digests, this forum seems to be for 
advanced

and professional programmers.

So wondering if a newbie can post some questions to understand errors in his 
code

or will it look silly?

 Thanks,

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

Re: Questions.

[Michael Torrie]

On 09/08/2017 08:35 PM, V Vishwanathan wrote:
> Hi, From what I see in the recent 4/5 digests, this forum seems to be for 
> advanced
> 
> and professional programmers.
> 
> So wondering if a newbie can post some questions to understand errors in his 
> code
> 
> or will it look silly?

Yes you may indeed post here.  There's also a beginners list called
python-help, which may seem less intimidating.  If you do post with a
question, be sure to copy and paste a complete traceback of any
exceptions your program is raising.  Also if you can, post a small but
runnable code snippet that demonstrates the problem you are having.

This list does tend to run off into the weeds fairly quickly on many
threads, but usually you can get some good assistance before that happens.

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

Re: Questions.

[Skip Montanaro]

> Hi, From what I see in the recent 4/5 digests, this forum seems to be for 
> advanced and professional programmers.
>
> So wondering if a newbie can post some questions to understand errors in his 
> code or will it look silly?

While there are professional programmers here, and some questions
explore various dark corners of the language and its libraries, the
experience level runs the gamut, from people just learning the
language to core developers. So, fire away. It does help if you don't
ask us to do your homework for you. :-)

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

Re: Questions.

[boB Stepp]

On Fri, Sep 8, 2017 at 9:54 PM, Michael Torrie  wrote:
> On 09/08/2017 08:35 PM, V Vishwanathan wrote:
>> Hi, From what I see in the recent 4/5 digests, this forum seems to be for 
>> advanced
>>
>> and professional programmers.
>>
>> So wondering if a newbie can post some questions to understand errors in his 
>> code
>>
>> or will it look silly?
>
> Yes you may indeed post here.  There's also a beginners list called
> python-help, which may seem less intimidating.

That would be Python Tutor.  Subscription information may be found at

https://mail.python.org/mailman/listinfo/tutor

It is a moderated list, so there may be a short delay before your
first post(s) may come through.



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

Re: Not appending ("lib") to sys.path breaks tests.

[Ian Kelly]

On Fri, Sep 8, 2017 at 3:54 PM, Leam Hall  wrote:
> On 09/08/2017 05:41 PM, Ian Kelly wrote:
>
>> I'm confused about where the character_tools import is made. If that's
>> within a module in the lib package, it should be fine.
>
>
>> It looks like it's failing to find the lib package. Since you removed
>> the "lib" directory from sys.path, does its parent directory exist in
>> sys.path?
>
>
> The path is not in the modules path or in sys.path. Hence the append. I
> thought I could add the local "lib" path via "." or "lib.", but it seems
> not.
>
> import lib.character fails in the tests/ directory.

Certainly not "lib.". The paths in sys.path need to be valid
filesystem paths for your OS. However, "." works for me:

(xenial)ikelly@localhost:~$ mkdir lib
(xenial)ikelly@localhost:~$ touch lib/__init__.py
(xenial)ikelly@localhost:~$ touch lib/character.py
(xenial)ikelly@localhost:~$ python3
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import lib.character
>>>
(xenial)ikelly@localhost:~$ mkdir tests
(xenial)ikelly@localhost:~$ echo "import lib.character" >
tests/test_character.py
(xenial)ikelly@localhost:~$ python3 tests/test_character.py
Traceback (most recent call last):
  File "tests/test_character.py", line 1, in 
import lib.character
ImportError: No module named 'lib'
(xenial)ikelly@localhost:~$ export PYTHONPATH=.
(xenial)ikelly@localhost:~$ python3 tests/test_character.py
(xenial)ikelly@localhost:~$

The only thing I can think of is to question what the CWD is when
you're running the test. If it's not the parent directory of lib, then
of course "." wouldn't work.

Note from the transcript that when running interactively, '' (which is
equivalent to '.') is automatically prepended to sys.path, whereas
when running a script, the absolute path of the directory containing
the script is prepended instead. That's why PYTHONPATH needed to be
set for the second test but not the first.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using Python 2

[Terry Reedy]

On 9/8/2017 12:27 PM, Steve D'Aprano wrote:

On Sat, 9 Sep 2017 12:23 am, Leam Hall wrote:



If Python 3 is not a total re-write then why break
compatibility?


To avoid building up excess cruft in the language.

To fix design mistakes which cannot be fixed without a backwards-incompatible
change.


One of the semi-myths about 3.0 is that is was somehow unique in 
breaking backward compatibility.  Python has always (for last 2 decades, 
anyway) has a procedure of deprecation and removal of old stuff.  What 
happened is that about 2.4, or whenever planning for 3.0 became serious, 
removals were mostly delayed until 3.0.  For instance, the original 
proposal for changing 1/2 from being 0 to being .5 proposed doing it in 
2.5.  Instead it was delayed to 3.0.  Without the prospect of 3.0, it 
would have happened sooner.


One change during 2.x that was not delayed was the removal of string 
exceptions.


So far during 3.x, at least a few modules have been deprecated and 
scheduled to be removed.  But when support for 2.7 was extended another 
5 years, we decided to delay such removals until after 2.7 support ends, 
in order to ease porting.


--
Terry Jan Reedy

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

Key Error: "city"

[V Vishwanathan]

(1) Trying to convert concatenated string to .format method
(2) concatenated string >>
[#todo rewrite this line to use the format method rather than string 
concatenation
alert = "Today's forecast for " + city + ": The temperature will range from " + 
str(low_temperature) + " to " + str(high_temperature) + " " + temperature_unit 
+ ". Conditions will be " + weather_conditions + "."]

(3) My code:
city = "Seoul"
high_temperature = 18
low_temperature = 9
temperature_unit = "degrees Celsius"
weather_conditions = "light rain"
alert = "Today's forecast for {city}: The temperature will range 
from{low_temperature} "" to ""{high_temperature}{temperature_unit}Conditions 
will be 
{weather_conditions}".format(city,low_temperature,high_temperature,temperature_unit,weather_conditions)
print(alert)

(4) output:

Traceback (most recent call last):
  File "D:\python exercises\uda format1.py", line 6, in 
alert = "Today's forecast for {city}: The temperature will range 
from{low_temperature} "" to ""{high_temperature}{temperature_unit}Conditions 
will be 
{weather_conditions}".format(city,low_temperature,high_temperature,temperature_unit,weather_conditions)
KeyError: 'city'

 (5) Tried Google but not much help.

So would appreciate any help.
Thanks,
Venkat
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Key Error: "city"

[Ben Finney]

V Vishwanathan  writes:

> alert = "Today's forecast for {city}: The temperature will range 
> from{low_temperature} "" to ""{high_temperature}{temperature_unit}Conditions 
> will be 
> {weather_conditions}".format(city,low_temperature,high_temperature,temperature_unit,weather_conditions)
> print(alert)

The ‘str.format’ method accepts positional arguments and keyword
arguments.

When you want to refer to the arguments by name, the method must know
their names; that means passing them to the method as keyword arguments.

> Traceback (most recent call last):
>   File "D:\python exercises\uda format1.py", line 6, in 
> alert = "Today's forecast for {city}: The temperature will range 
> from{low_temperature} "" to ""{high_temperature}{temperature_unit}Conditions 
> will be 
> {weather_conditions}".format(city,low_temperature,high_temperature,temperature_unit,weather_conditions)
> KeyError: 'city'

Your format string refers to keys (names) that are not found in the
dictionary of keyword arguments — because you passed no keyword
arguments.

Instead, give a keyword argument for each name you want to refer to in
the format string.

-- 
 \  “There's a certain part of the contented majority who love |
  `\anybody who is worth a billion dollars.” —John Kenneth |
_o__)Galbraith, 1992-05-23 |
Ben Finney

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

Re: Hatch - A modern project, package, and virtual env manager

[ofekmeister]

Temporary venvs support and terminal colors in 0.8.0! 
https://github.com/ofek/hatch#080
-- 
https://mail.python.org/mailman/listinfo/python-list

Case Solution: Doing Business in Sierra Leone Graeme Hossie at London Mining (A) by Brian C. Pinkham, Ken Mark

[sonamdemapuku]

What priorities should hossie consider? 
What are some of the concerns around enforcement of the contract? 
How should hossie carry out negotiations? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Hat difference between "" and '' in string definition

[Andrej Viktorovich]

Hello,

What is difference between string definitions:
s="aaa"
and
s='bbb'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Merge pdf files using information from two files

[dieter]

accessnew...@gmail.com writes:
> I have two files (right now they are spreadsheets but I can export them to 
> any format). 
>
> File1 has StoreID (unique) in one column and a pdf map location in the second 
> column. (Names not really sequenced numerically)
>
> 1 C:/maps/map1.pdf
> 2 C:/maps/map2.pdf
> 3 C:/maps/map3.pdf
> 4 C:/maps/map4.pdf
>
> File2 has 3 columns. Column1 is the County name (unique), Column2 are the 
> store IDs that fall in that county separated by commas, and Column3 is 
> warehouse that services the store.
>
> County11,2Warehouse1
> County21,3Warehouse1
> County33  Warehouse4
> County42,4Warehouse3
>
> Is it possible to compare both files and append the maps that belong in each 
> county and naming it by the county_warehouse.pdf?

This will not be easy: PDF is a page layout oriented format, not
a format to facilitate the processing of general structural
data (such as e.g. XML).

You could use a package like "pdfminer" to get at the text content
of a PDF file. You will then need specialized code (developed by yourself)
to reconstruct the column information.
You could then use a PDF generating package such as "reportlab"
to generate a new PDF file.

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