Re: Proposed keyword to transfer control to another function

[Antoon Pardon]

On 07/17/2015 01:46 AM, Chris Angelico wrote:
> Open for bikeshedding: What should the keyword be? We can't use
> "exec", which would match Unix and shell usage, because it's already
> used in a rather different sense in Python. Current candidates:
> "transfer", "goto", "recurse", and anything else you suggest.

I propose the combination "return from". I think it is similar enough
with "yield from" to justify this and it also won't need an extra
keyword, so no programs will be broken because they used "transfer",
"goto" or whatever other new keyword as an identifier.

Should there be someone who is willing to spend time on this, I wish
him all luck and strength he can find. I think it would be best if
it was done by someone who is interrested in using this in his own
programs. Because it is all very fine talking about the pro and
cons here and I certainly would use it, the question is, how wide
spread would the use become and is it worth the time and effort to
introduce it. If future use turns out to be disappointing such a
coder can at least think of it as something that was useful for
himself.

-- 
Antoon.


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

Re: A new module for performing tail-call elimination

[Antoon Pardon]

On 07/16/2015 09:34 PM, Terry Reedy wrote:
> On 7/16/2015 3:45 AM, Antoon Pardon wrote:
>> On 07/15/2015 11:19 PM, Terry Reedy wrote:
>>>
>>> I believe that this pattern should work with any set of mutually
>>> recursive functions that always call each other in cyclic order.  A
>>> more elaborate version does not have this limitation.
>>>
>>
>> Nice of you to illustrate the warping involved.  ;-)
>
> Glad you appreciate it. To me, the warping is no more than, and
> perhaps less than, and certainly less obnoxious than,the warping
> required when using Baruchel's tco module.  (Opinions can vary,
> of course.)  The result will definitely run faster than with B's tco.

I don't care about the speed that much. Clarity of code is more important.
And I agree how Baruchel's tco module needs to be used, doesn't seem
very helpful in that respect. I wouldn't call it obnoxious, cause I
can appreciate the mathematical elegance behind it, but my impression is
that understanding what is going on, requires a back ground knowledge
that is generally not expected. So using this would probably be good for
job security but wouldn't be fair to my colleagues.

-- 
Antoon Pardon

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

Re: A new module for performing tail-call elimination

[Robin Becker]

On 16/07/2015 17:17, Ian Kelly wrote:

On Thu, Jul 16, 2015 at 3:28 AM, Robin Becker  wrote:

.



I believe the classic answer is Ackermann's function

http://demonstrations.wolfram.com/RecursionInTheAckermannFunction/

which is said to be not "primitive recursive" ie cannot be unwound into
loops; not sure whether that implies it has to be recursively defined or can
perhaps be broken down some other way.



that should have said "simple loops"



My recollection -- and it's been awhile since I've studied
computability theory so I may be distorting things here -- is that
primitive recursive functions can be computed using for loops, i.e.
loops where the number of iterations is bounded in advance, whereas
non-primitive recursive functions require while loops.

I'm guessing, but is the implication that for loops can be specified finitely in 
advance, but while loops need some processing in the calculation to determine 
termination? I'm an engineer :(

--
Robin Becker

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

Re: A new module for performing tail-call elimination

[Antoon Pardon]

On 07/16/2015 08:58 PM, Steven D'Aprano wrote:
>> Nice of you to illustrate how being pedantic about something, can
>> make a response useless with regard to the intended original question.
> Just because your intention in giving that code was X, doesn't mean that
> others cannot use that code to also do Y.
>
> Your example of a mutually recursive pair of functions is perfectly fine as
> a toy example to demonstrate a point. But the fact that people can only
> come up with toy examples to demonstrate the uses of unbounded recursion is
> telling. That's *my* point. It's orthogonal to your point.

We know your point. You have repeated it often enough. There is no need
to keep bringing it up and certainly not where your point is irrelevant.

People are allowed to not care about your point. People may think it is
not worth the trouble trying to convince people who are skeptical and
may choose to discuss possible directions with people who are likewise 
intressed.

So why do you find it necessary to appear here and repeat your point,
that is already known, but is not cared about much and irrelevant here.


>> I'm not here to satisfy your or anyone else's curiosity. 
> Fair enough.
>
> What are you here for? When you complain that Python doesn't have TCO, is
> your intent to persuade people that it should, with the ultimate aim to
> changing Python so that it gains TCO? If not, then what?

I don't complain that Python doesn't have TCO. I am intressed in the subject
and I'm willing to discuss the pro and cons, how it could be simulated, and
how good some arguments for or against it are. But I don't think any outcome
here will have much weight in getting it implemented and although I would
prefer having it, I can perfectly live without. So don't translate my
interest in the subject into a complaint about python not having it.

I'm also not interrested in convincing people who show a dislike for it.
If the toy examples here, don't ignite a spark of imagination about how
in some circumstance this could be useful for you, then I am not interessed
in showing you.

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

Re: Noob in Python. Problem with fairly simple test case

[Jean-Michel Pichavant]

- Original Message -
> From: "Steven D'Aprano" 
> 75% or 90% is not a "vast majority". Vast majority implies more than
> 99%.

You could not be more wrong.

More than 99% is a stupendous majority, while within 95 to 99% is a tremendous 
majority.
>From the official "Majority rating" 2015 edition, a vast majority would be 
>between 87 and 87.6%.

Of course this is only valid in the northern hemisphere (my apologies for 
stating the obvious).

JM



-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be 
privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for 
any purpose, or store or copy the information in any medium. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed keyword to transfer control to another function

[Terry Reedy]

On 7/17/2015 3:17 AM, Antoon Pardon wrote:

On 07/17/2015 01:46 AM, Chris Angelico wrote:

Open for bikeshedding: What should the keyword be? We can't use
"exec", which would match Unix and shell usage, because it's already
used in a rather different sense in Python. Current candidates:
"transfer", "goto", "recurse", and anything else you suggest.


I propose the combination "return from".


Much better.  I believe 'yield from' actually cuts out the middle frame
containing yield from.


--
Terry Jan Reedy

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

Re: Proposed keyword to transfer control to another function

[Chris Angelico]

On Fri, Jul 17, 2015 at 5:17 PM, Antoon Pardon
 wrote:
> On 07/17/2015 01:46 AM, Chris Angelico wrote:
>> Open for bikeshedding: What should the keyword be? We can't use
>> "exec", which would match Unix and shell usage, because it's already
>> used in a rather different sense in Python. Current candidates:
>> "transfer", "goto", "recurse", and anything else you suggest.
>
> I propose the combination "return from". I think it is similar enough
> with "yield from" to justify this and it also won't need an extra
> keyword, so no programs will be broken because they used "transfer",
> "goto" or whatever other new keyword as an identifier.
>

Oooh I like this. The parallel makes sense, and as you say, no new
keyword. Yes, "return from" is my new preferred command!

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

Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Antoon Pardon]

On 07/16/2015 06:43 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 12:32 AM, Antoon Pardon
>  wrote:
>
>> What is unclear about "as it is generally produced on stderr"? That you
>> can do a whole lot of stuff, doesn't mean that this whole lot of stuff is
>> part of what generally happens. When people on this list ask a person
>> to include the stacktrace with the description of the problem, they
>> don't mean something that includes the values of the variables.
> True. That said, though, it's not a justification for dropping stack
> frames; even in the form that's printed to stderr, there is immense
> value in them. It may be possible to explicitly drop frames that a
> programmer believes won't be useful, but a general and automated
> dropping of tail-call information will do more harm than good. The
> fact that some frameworks can show _even more_ helpful information out
> of a traceback only makes this stronger.

Just wondering, are traceback records of generators available? They are
if an exception is raised in the generator itself, but what if an exception
is raised in the loop that is driven by a generator. They don't appear in
the standard stack trace. 

It seems a bit strange that with the immense value that is given to 
stack frames, that these wouldn't be available somehow.

-- 
Antoon Pardon

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

Re: Noob in Python. Problem with fairly simple test case

[Chris Angelico]

On Fri, Jul 17, 2015 at 4:47 PM, Steven D'Aprano  wrote:
>> Jessie's default should be 2.7, at least. Wheezy shipped 2.7, too;
>> it's only Squeeze (now out of support) that didn't ship any 2.7.x
>> Python. Are you sure you can't at least upgrade to 2.7?
>
> I'm not sure, I'm not actively involved in that specific project. All I know
> is that the guys are always complaining about Jessie, and that they're
> using 2.6.

Huh. Then maybe it's the other way: Jessie no longer ships or supports
2.6, so if 2.7 breaks the code, then so will Jessie. But I'm looking
over the 2.7 What's New page, and it honestly doesn't jump out at me
screaming "Your code will break!". Strange.

Anyway, the specifics don't matter. What matters is that there *are*
people who are using the system-provided Python, and that (so far)
that's Py2 for the majority of Linux distros. But that's definitely
changing; Ubuntu and Debian are both aiming toward a state of "ship
Python 3 by default, but if you want 2.7, you'll have to download it",
which implies that all system scripts will be ported to 3.x. Once that
happens, I expect that all Debian-derived distros will follow pretty
quickly (it's easy to transition if someone else has already done the
vast majority of the work, by which I clearly mean about 87.4%), and
non-Debian distros can probably take advantage of the prior work too,
to some extent. That'll shift the balance on Linux from "mostly Py2"
to "mostly Py3", and that'll have knock-on effects on Windows and Mac
OS too, as third-party script developers will find it advisable [1] to
write their code to match the predominantly available version.

> My guess is, the rate of Python 3 adoption is going to hit the tipping point
> in 2 or 3 years, after which time it will be *very* rapid.

Yep, I'd agree with that estimate. Debian Stretch (9) may or may not
switch; I'd be very surprised if Debian Buster (10) didn't have Py3 by
default.

ChrisA

[1] The question is, what did the archbishop find?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Chris Angelico]

On Fri, Jul 17, 2015 at 8:48 PM, Antoon Pardon
 wrote:
> Just wondering, are traceback records of generators available? They are
> if an exception is raised in the generator itself, but what if an exception
> is raised in the loop that is driven by a generator. They don't appear in
> the standard stack trace.

Not sure what you mean here. Something like this?

def gen():
yield stuff
yield more stuff

for stuff in gen():
bomb with exception

The error didn't happen in the generator, so I wouldn't expect to see
it in the traceback. There's still room for the cause of an error to
not be in the traceback; imagine, for instance, a function that
populates a concrete list, and then you iterate over the list. If that
function sticks a None into the list and the subsequent processing is
expecting all strings, that's going to bomb, but then you have to
figure out where the None came from. If the traceback could include
that, it'd be great, but some things aren't possible. Doesn't mean
we're happy to sacrifice other functionality.

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

eGenix at the EuroPython Conference 2015

[eGenix Team: M.-A. Lemburg]

eGenix.com at the EuroPython Conference 2015

 July 20-26 2015
  Bilbao, Spain


  Meet up with eGenix at this year's EuroPython Conference in Bilbao.
  We have free project, consulting and coaching capacities.



The EuroPython Conference (https://ep2015.europython.eu/) is the one
of the premier conferences for Python users and developers in
Europe. It is the second largest gathering of Python enthusiast around
the world. This year it is being held from July 20-26 in Bilbao,
Spain.

This announcement is also available on our web-site for online reading:
http://www.egenix.com/company/news/EuroPython-Conference-2015.html



Meet up with eGenix at EuroPython

eGenix was one of the founding members of the EuroPython conference
team and played a major role in organizing the first EuroPython
conference in the year 2002.

Since then we have attended every EuroPython conference to meet up
face-to-face with the many people we know from the Python community
and the many people that we don't yet know from the community -- if
you are interested in meeting with us, please drop us a note so that
we can arrange a meeting at i...@egenix.com.



eGenix Talks at EuroPython

At this year's EuroPython, Marc-André Lemburg, CEO of eGenix, will be
giving a talk providing some guidance for programmers new to Python:

Python idioms to help you write good code
-

*Avoid gotchas, write faster, more readable and maintainable code*

Python focuses a lot on writing readable code and also tries to
make solutions obvious, but this doesn’t necessarily mean that you
cannot write unreadable code or design your code in ways which
makes it hard to extend or maintain.

This talk will show some useful idioms to apply when writing
Python code, how to structure your modules and also goes into
details on which techniques to use and which to think about twice,
based on 20 years of experience writing Python.

Tuesday 21 July at 15:15 CEST, Google Room


https://ep2015.europython.eu/conference/talks/python-idioms-to-help-you-write-good-code



Free project, consulting and coaching capacities

eGenix currently has free custom Python project, consulting and
coaching capacities.

If you are interested in having eGenix implement your great ideas in
Python, or want to have your teams benefit from our long Python coding
experience, please contact us at i...@egenix.com.

If you happen to attend EuroPython, you can also talk to our CEO
Marc-André Lemburg directly. Please email him to arrange a meeting:
m...@egenix.com.

Enjoy,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 17 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2015-07-20: EuroPython 2015, Bilbao, Spain ...  3 days to go
2015-07-29: Python Meeting Duesseldorf ... 12 days to go

: Try our mxODBC.Connect Python Database Interface for free ! ::

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

Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Antoon Pardon]

On 07/17/2015 01:05 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 8:48 PM, Antoon Pardon
>  wrote:
>> Just wondering, are traceback records of generators available? They are
>> if an exception is raised in the generator itself, but what if an exception
>> is raised in the loop that is driven by a generator. They don't appear in
>> the standard stack trace.
> Not sure what you mean here. Something like this?
>
> def gen():
> yield stuff
> yield more stuff
>
> for stuff in gen():
> bomb with exception
>
> The error didn't happen in the generator, so I wouldn't expect to see
> it in the traceback.

Yes something like that. And I wouldn't expect it either but if it
is not present, is it because nobody thought about it or because it
is a bad idea or an idea difficult to implement?

> There's still room for the cause of an error to
> not be in the traceback; imagine, for instance, a function that
> populates a concrete list, and then you iterate over the list. If that
> function sticks a None into the list and the subsequent processing is
> expecting all strings, that's going to bomb, but then you have to
> figure out where the None came from. If the traceback could include
> that, it'd be great, but some things aren't possible.

Sure, but in this case, the generator is still active. The Runtime
would be able to jump to and somehow activates it's stack record
for the next value. So why would we expect it to be impossible to
include this trace back record in a stack trace?

>  Doesn't mean
> we're happy to sacrifice other functionality.

Indeed, this is an independend problem. Whatever the answer here doesn't
need to affect how one feels about losing trace back record because of
TCO.


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

Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Chris Angelico]

On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
 wrote:
> On 07/17/2015 01:05 PM, Chris Angelico wrote:
>> On Fri, Jul 17, 2015 at 8:48 PM, Antoon Pardon
>>  wrote:
>>> Just wondering, are traceback records of generators available? They are
>>> if an exception is raised in the generator itself, but what if an exception
>>> is raised in the loop that is driven by a generator. They don't appear in
>>> the standard stack trace.
>> Not sure what you mean here. Something like this?
>>
>> def gen():
>> yield stuff
>> yield more stuff
>>
>> for stuff in gen():
>> bomb with exception
>>
>> The error didn't happen in the generator, so I wouldn't expect to see
>> it in the traceback.
>
> Yes something like that. And I wouldn't expect it either but if it
> is not present, is it because nobody thought about it or because it
> is a bad idea or an idea difficult to implement?
>
>> There's still room for the cause of an error to
>> not be in the traceback; imagine, for instance, a function that
>> populates a concrete list, and then you iterate over the list. If that
>> function sticks a None into the list and the subsequent processing is
>> expecting all strings, that's going to bomb, but then you have to
>> figure out where the None came from. If the traceback could include
>> that, it'd be great, but some things aren't possible.
>
> Sure, but in this case, the generator is still active. The Runtime
> would be able to jump to and somehow activates it's stack record
> for the next value. So why would we expect it to be impossible to
> include this trace back record in a stack trace?

Python could also give you stack traces for any other threads that are
concurrently running, on the off-chance that one of them affected it.
But the only influence the generator has on the loop is to yield a
value or signal termination; if an exception is thrown in the loop
itself, the local name 'stuff' should have all the information about
that cause. Python isn't a mind-reader, no matter how much it may look
like one, and it can't know that this function's return value should
be shown as part of a completely different function's stack trace.

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

Re: ANN: eGenix PyRun - One file Python Runtime 2.1.0

[Alex]

They don't offer any free versions for those systems and their licenses are
quite expensive.

On Fri, Jul 17, 2015 at 2:26 AM, Laura Creighton  wrote:

> I think Activestate makes a Python 2.y for Solaris.
> http://www.activestate.com/activepython
>
> I've never used it.
>
> Laura
>
> In a message of Thu, 16 Jul 2015 18:58:37 -0400, Alex writes:
> >Do you have Python 2.7 64bit versions available for Solaris (10/11)
> >x86/SPARC, AIX, and HP-UX IA/RISC? I've had the displeasure of having to
> >install 64bit Python on Solaris and AIX and it's an experience I would not
> >recommend even though OpenCSW and Perzl have done much of the legwork
> >already. I'd also just be happy with any pointers to building PyRun or
> >regular Python on such systems if such currently there exist no such
> builds.
> >
> >On Wed, May 13, 2015 at 10:34 AM, Cristiano Cortezia <
> >cristiano.corte...@gmail.com> wrote:
> >
> >> In one of the next releases we'll probably add a tool to bundle
> >>> complete applications together with pyrun, perhaps even by
> >>> recompiling it to include the application byte code files
> >>> right in the binary like we do for the stdlib.
> >>
> >>
> >> Well, that would be simply awesome. Looking forward to it.
> >>
> >> PS: you guys should definitely advertise this work on the embedded
> >> software community.
> >>
> >>
> >> 2015-05-13 11:29 GMT-03:00 M.-A. Lemburg :
> >>
> >>> On 13.05.2015 16:09, Cristiano Cortezia wrote:
> >>> > Well I gave it a try, and it seems my assumptions were *somehow*
> true.
> >>> > Here is what I got when running one of my apps in single shot mode
> >>> (load,
> >>> > run, terminate):
> >>> >
> >>> > *default python distribution*
> >>> > total time 9.022s
> >>> > ENOENT's count 7377
> >>> >
> >>> > *pyrun*
> >>> > total time 8.455s
> >>> > ENOENT's count 3064
> >>> >
> >>> > So, it indeed failed much less to open files, but I guess this didn't
> >>> make
> >>> > that much difference after all (500ms).
> >>>
> >>> PyRun has the advantage of being able to read the byte code
> >>> directly from the binary (using memory mapping). However,
> >>> it still needs to run the same startup machinery as Python
> >>> itself.
> >>>
> >>> Note that startup time for Python was a lot worse before
> >>> Python used the same approach as PyRun to compile in the
> >>> parsed sysconfig data.
> >>>
> >>> > Perhaps it is because this app has some external dependencies (22 to
> be
> >>> > precise) not bundled on pyrun that had to be scanned by the
> interpreter
> >>> > anyway. If by any means we could bundle them all the same way, than
> it
> >>> > could bring a much higher performance gain. But I guess it is not
> really
> >>> > safe-feasible.
> >>>
> >>> It's certainly possible to use the pyrun build system to create
> >>> bundles with more packages and tools included.
> >>>
> >>> The one we're shipping has most of the stdlib included,
> >>> but leaves all the application code to reside on the
> >>> sys.path or in a ZIP archive.
> >>>
> >>> In one of the next releases we'll probably add a tool to bundle
> >>> complete applications together with pyrun, perhaps even by
> >>> recompiling it to include the application byte code files
> >>> right in the binary like we do for the stdlib.
> >>>
> >>> --
> >>> Marc-Andre Lemburg
> >>> eGenix.com
> >>>
> >>> Professional Python Services directly from the Source  (#1, May 13
> 2015)
> >>> >>> Python Projects, Coaching and Consulting ...
> http://www.egenix.com/
> >>> >>> mxODBC Plone/Zope Database Adapter ...
> http://zope.egenix.com/
> >>> >>> mxODBC, mxDateTime, mxTextTools ...
> http://python.egenix.com/
> >>>
> 
> >>> 2015-05-13: Released mxODBC Connect 2.1.3 ...
> http://egenix.com/go75
> >>> 2015-05-11 : Released eGenix PyRun
> >>> 2.1.0 ...   http://egenix.com/go74
> >>> 2015-05-25 : PyWaw Summit 2015,
> >>> Warsaw, Poland ...  12 days to go
> >>>
> >>>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> >>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> >>>Registered at Amtsgericht Duesseldorf: HRB 46611
> >>>http://www.egenix.com/company/contact/
> >>>
> >>
> >>
> >> --
> >> https://mail.python.org/mailman/listinfo/python-list
> >>
> >>
> >
> >--
> >https://mail.python.org/mailman/listinfo/python-list
> >
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Antoon Pardon]

On 07/17/2015 01:49 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
>  wrote:
>
>
>> Sure, but in this case, the generator is still active. The Runtime
>> would be able to jump to and somehow activates it's stack record
>> for the next value. So why would we expect it to be impossible to
>> include this trace back record in a stack trace?
> Python could also give you stack traces for any other threads that are
> concurrently running, on the off-chance that one of them affected it.
> But the only influence the generator has on the loop is to yield a
> value or signal termination; if an exception is thrown in the loop
> itself, the local name 'stuff' should have all the information about
> that cause.

But the local name 'stuff' may only have the information for the immediate
cause. The underlying cause may be available in the generator. Suppose
you have a generator that should only generate positive numbers that you
use to divide some other number by. Your loop crashes because of a 
DivideByZeroError
Sure the local name shows the dividor to be zero, but you have no
information on why your generator produced a zero, but there may be a
clue in the trace back record of the generator.

>  Python isn't a mind-reader, no matter how much it may look
> like one, and it can't know that this function's return value should
> be shown as part of a completely different function's stack trace.

It is not a matter of mindreading. And it is not a completely different
functions stack trace. It is the trace back record of a generator that
is used by the process/thread that crashed. And AFAIK an active generator
belongs to one specific thread. You can't have it yield a value to a different
thread and you can't send it a value from an other thread. So I really
see no reason to exclude the trace back records of active generators
from a stack trace of a crashed thread.

-- 
Antoon Pardon

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

Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Chris Angelico]

On Fri, Jul 17, 2015 at 10:54 PM, Antoon Pardon
 wrote:
> On 07/17/2015 01:49 PM, Chris Angelico wrote:
>> On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
>>  wrote:
>>
>>
>>> Sure, but in this case, the generator is still active. The Runtime
>>> would be able to jump to and somehow activates it's stack record
>>> for the next value. So why would we expect it to be impossible to
>>> include this trace back record in a stack trace?
>> Python could also give you stack traces for any other threads that are
>> concurrently running, on the off-chance that one of them affected it.
>> But the only influence the generator has on the loop is to yield a
>> value or signal termination; if an exception is thrown in the loop
>> itself, the local name 'stuff' should have all the information about
>> that cause.
>
> But the local name 'stuff' may only have the information for the immediate
> cause. The underlying cause may be available in the generator. Suppose
> you have a generator that should only generate positive numbers that you
> use to divide some other number by. Your loop crashes because of a 
> DivideByZeroError
> Sure the local name shows the dividor to be zero, but you have no
> information on why your generator produced a zero, but there may be a
> clue in the trace back record of the generator.

Indeed, but there's nothing special about generators here. The same
sequence could have been a concrete list, or it could have been some
other kind of iterator (any object with __iter__ and __next__), which
won't have a stack frame. Special cases aren't special enough to warp
exception handling around.

>>  Python isn't a mind-reader, no matter how much it may look
>> like one, and it can't know that this function's return value should
>> be shown as part of a completely different function's stack trace.
>
> It is not a matter of mindreading. And it is not a completely different
> functions stack trace. It is the trace back record of a generator that
> is used by the process/thread that crashed. And AFAIK an active generator
> belongs to one specific thread. You can't have it yield a value to a different
> thread and you can't send it a value from an other thread. So I really
> see no reason to exclude the trace back records of active generators
> from a stack trace of a crashed thread.

No, generators are fine across threads:

rosuav@sikorsky:~$ python3 threadgen.py
Starting!
First yielded value
Continuing!
Second yielded value
Terminating.
Traceback (most recent call last):
  File "threadgen.py", line 20, in 
print(next(gen))
StopIteration
rosuav@sikorsky:~$ cat threadgen.py
import threading
import time

def thread():
time.sleep(0.5)
print(next(gen))

threading.Thread(target=thread).start()

def generator():rosuav@sikorsky:~$

print("Starting!")
yield "First yielded value"
print("Continuing!")
yield "Second yielded value"
print("Terminating.")

gen = generator()
print(next(gen))
time.sleep(1)
print(next(gen))
rosuav@sikorsky:~$

In fact, a generator doesn't have a stack unless it's currently
executing, so all you could get is whatever's actually inside it (that
is, if there's a deep tree of 'yield from's, you could dig up that
part of the stack). I'm not sure this would really help you very much.

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

Re: How does a dictionary work exactly?

[Ned Batchelder]

On Thursday, July 16, 2015 at 2:59:02 PM UTC-4, Skip Montanaro wrote:
> On Thu, Jul 16, 2015 at 1:36 PM, yoursurrogate...@gmail.com
>  wrote:
> > If I understand correctly, lookup would not be a constant, yes?
> 
> On the contrary, that's what you desire, nearly constant time
> execution. To the greatest extent possible, you want the linked lists
> to be of length zero or one. Part of the magic is in figuring out good
> places to expand the size of the hash array. You don't want it to grow
> too big, but you still want most linked lists to be very short. The
> resize operation isn't done too often because it itself is expensive.
> I believe Python dicts start out with an overly large initial hash
> array (again, dredging up old memories of threads on python-dev) as an
> optimization to avoid lots of early resize operations.
> 
> Skip

Maybe people are reading a different implementation than I am.  Python's
dict object doesn't use linked lists to deal with hash collisions, it probes
other slots instead.

Brandon Rhodes did a great talk about how dicts work:
http://pyvideo.org/video/276/the-mighty-dictionary-55

BTW: The Python 3 implementation is more complicated than in Python 2, I
think to deal with sharing keys among dictionaries that have the same set
of keys.

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

Re: ANN: eGenix PyRun - One file Python Runtime 2.1.0

[M.-A. Lemburg]

Hi Alex,

On 17.07.2015 00:58, Alex wrote:
> Do you have Python 2.7 64bit versions available for Solaris (10/11)
> x86/SPARC, AIX, and HP-UX IA/RISC? I've had the displeasure of having to
> install 64bit Python on Solaris and AIX and it's an experience I would not
> recommend even though OpenCSW and Perzl have done much of the legwork
> already. I'd also just be happy with any pointers to building PyRun or
> regular Python on such systems if such currently there exist no such builds.

We don't currently have direct access to these types of systems, so
cannot provide regular builds for these platforms.

For AIX and Solaris x86 we do provide custom paid support to get
our software ported, if you're interested in this.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 17 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2015-07-20: EuroPython 2015, Bilbao, Spain ...  3 days to go
2015-07-29: Python Meeting Duesseldorf ... 12 days to go

: Try our mxODBC.Connect Python Database Interface for free ! ::

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


> On Wed, May 13, 2015 at 10:34 AM, Cristiano Cortezia <
> cristiano.corte...@gmail.com> wrote:
> 
>> In one of the next releases we'll probably add a tool to bundle
>>> complete applications together with pyrun, perhaps even by
>>> recompiling it to include the application byte code files
>>> right in the binary like we do for the stdlib.
>>
>>
>> Well, that would be simply awesome. Looking forward to it.
>>
>> PS: you guys should definitely advertise this work on the embedded
>> software community.
>>
>>
>> 2015-05-13 11:29 GMT-03:00 M.-A. Lemburg :
>>
>>> On 13.05.2015 16:09, Cristiano Cortezia wrote:
 Well I gave it a try, and it seems my assumptions were *somehow* true.
 Here is what I got when running one of my apps in single shot mode
>>> (load,
 run, terminate):

 *default python distribution*
 total time 9.022s
 ENOENT's count 7377

 *pyrun*
 total time 8.455s
 ENOENT's count 3064

 So, it indeed failed much less to open files, but I guess this didn't
>>> make
 that much difference after all (500ms).
>>>
>>> PyRun has the advantage of being able to read the byte code
>>> directly from the binary (using memory mapping). However,
>>> it still needs to run the same startup machinery as Python
>>> itself.
>>>
>>> Note that startup time for Python was a lot worse before
>>> Python used the same approach as PyRun to compile in the
>>> parsed sysconfig data.
>>>
 Perhaps it is because this app has some external dependencies (22 to be
 precise) not bundled on pyrun that had to be scanned by the interpreter
 anyway. If by any means we could bundle them all the same way, than it
 could bring a much higher performance gain. But I guess it is not really
 safe-feasible.
>>>
>>> It's certainly possible to use the pyrun build system to create
>>> bundles with more packages and tools included.
>>>
>>> The one we're shipping has most of the stdlib included,
>>> but leaves all the application code to reside on the
>>> sys.path or in a ZIP archive.
>>>
>>> In one of the next releases we'll probably add a tool to bundle
>>> complete applications together with pyrun, perhaps even by
>>> recompiling it to include the application byte code files
>>> right in the binary like we do for the stdlib.
>>>
>>> --
>>> Marc-Andre Lemburg
>>> eGenix.com
>>>
>>> Professional Python Services directly from the Source  (#1, May 13 2015)
>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>> mxODBC Plone/Zope Database Adapter ...   http://zope.egenix.com/
>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
>>> 
>>> 2015-05-13: Released mxODBC Connect 2.1.3 ... http://egenix.com/go75
>>> 2015-05-11 : Released eGenix PyRun
>>> 2.1.0 ...   http://egenix.com/go74
>>> 2015-05-25 : PyWaw Summit 2015,
>>> Warsaw, Poland ...  12 days to go
>>>
>>>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>>Registered at Amtsgericht Duesseldorf: HRB 46611
>>>http://www.egenix.com/company/contact/
>>>
>>
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>>

Re: How does a dictionary work exactly?

[Skip Montanaro]

On Fri, Jul 17, 2015 at 9:32 AM, Ned Batchelder  wrote:
> Maybe people are reading a different implementation than I am.  Python's
> dict object doesn't use linked lists to deal with hash collisions, it probes
> other slots instead.

No, I was working a) from memory, and b) not looking at the
implementation, which I last did a long, long time ago...

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

Re: Need assistance

[Rob Gaddi]

On Thu, 16 Jul 2015 19:15:38 -0700, craig.sirna wrote:

> I need help writing a homework program.
> 
> I'll write it, but I can't figure out how to incorporate what I have
> read in the book to work in code.
> 
> The assignment wants us to take a users first, middle and last name in a
> single input ( name=('enter your full name: )).
> 
> Then we must display the full name rearranged in Last, First Middle
> order.
> 
> I tried to use the search function in Python to locate any spaces in the
> input. It spot back the index 5 (I used Craig Daniel Sirna)
> 
> That is correct for the first space, but I can't figure out how to get
> it to continue to the next space.
> 
> The indexing process is also a bit confusingto me.
> 
> I get that I can use len(fullName) to set the length of the index, and
> how the index is counted, but after that I'm lost.
> 
> I have emailed my professor a few times, but haven't gotten a
> response.(online course)
> 
> Any help would be greatly appreciated.

1) Use the interactive console.  Set x = 'Craig Daniel Sirna' and play 
with indexing and slicing it until you really internalize what they 
mean.  x[3], x[-3], x[0:10], x[0:-1].  It's not actually relevant to the 
problem at hand, but right now is the time in your education to get 
indexing down cold; skimp on it now and you'll pay for it forever.  
Should take you about 5 minutes.

2) https://docs.python.org/3/library/stdtypes.html#string-methods
You can do what you're trying to do, but you're swinging a hammer with a 
powered nailgun at your feet.  Search is an inefficient way to try to 
split a string into parts based on a delimiter.

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

Re: Need assistance

[Igor Korot]

 Hi, Rob,

On Fri, Jul 17, 2015 at 12:40 PM, Rob Gaddi
 wrote:
> On Thu, 16 Jul 2015 19:15:38 -0700, craig.sirna wrote:
>
>> I need help writing a homework program.
>>
>> I'll write it, but I can't figure out how to incorporate what I have
>> read in the book to work in code.
>>
>> The assignment wants us to take a users first, middle and last name in a
>> single input ( name=('enter your full name: )).
>>
>> Then we must display the full name rearranged in Last, First Middle
>> order.
>>
>> I tried to use the search function in Python to locate any spaces in the
>> input. It spot back the index 5 (I used Craig Daniel Sirna)
>>
>> That is correct for the first space, but I can't figure out how to get
>> it to continue to the next space.
>>
>> The indexing process is also a bit confusingto me.
>>
>> I get that I can use len(fullName) to set the length of the index, and
>> how the index is counted, but after that I'm lost.
>>
>> I have emailed my professor a few times, but haven't gotten a
>> response.(online course)
>>
>> Any help would be greatly appreciated.
>
> 1) Use the interactive console.  Set x = 'Craig Daniel Sirna' and play
> with indexing and slicing it until you really internalize what they
> mean.  x[3], x[-3], x[0:10], x[0:-1].  It's not actually relevant to the
> problem at hand, but right now is the time in your education to get
> indexing down cold; skimp on it now and you'll pay for it forever.
> Should take you about 5 minutes.
>
> 2) https://docs.python.org/3/library/stdtypes.html#string-methods
> You can do what you're trying to do, but you're swinging a hammer with a
> powered nailgun at your feet.  Search is an inefficient way to try to
> split a string into parts based on a delimiter.

Most likely it's not him. They will learn it later during the course. ;-)

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

Re: how do you play python because i have gone on the website but i haven't managed to code?

[sohcahtoa82]

On Thursday, July 16, 2015 at 12:31:04 PM UTC-7, Aron Barsam wrote:
> how do you play python because i have gone on the website but i haven't 
> managed to code?

http://i.imgur.com/x2KwTbw.jpg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed keyword to transfer control to another function

[sohcahtoa82]

On Friday, July 17, 2015 at 12:17:55 AM UTC-7, Antoon Pardon wrote:
> On 07/17/2015 01:46 AM, Chris Angelico wrote:
> > Open for bikeshedding: What should the keyword be? We can't use
> > "exec", which would match Unix and shell usage, because it's already
> > used in a rather different sense in Python. Current candidates:
> > "transfer", "goto", "recurse", and anything else you suggest.
> 
> I propose the combination "return from". I think it is similar enough
> with "yield from" to justify this and it also won't need an extra
> keyword, so no programs will be broken because they used "transfer",
> "goto" or whatever other new keyword as an identifier.
> 
> Should there be someone who is willing to spend time on this, I wish
> him all luck and strength he can find. I think it would be best if
> it was done by someone who is interrested in using this in his own
> programs. Because it is all very fine talking about the pro and
> cons here and I certainly would use it, the question is, how wide
> spread would the use become and is it worth the time and effort to
> introduce it. If future use turns out to be disappointing such a
> coder can at least think of it as something that was useful for
> himself.
> 
> -- 
> Antoon.

"return from" or "yield from" looks too much like a COMEFROM 
instruction/statement.

https://en.wikipedia.org/wiki/COMEFROM
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed keyword to transfer control to another function

[Ethan Furman]

On 07/17/2015 12:17 AM, Antoon Pardon wrote:

On 07/17/2015 01:46 AM, Chris Angelico wrote:

Open for bikeshedding: What should the keyword be? We can't use
"exec", which would match Unix and shell usage, because it's already
used in a rather different sense in Python. Current candidates:
"transfer", "goto", "recurse", and anything else you suggest.


I propose the combination "return from".


+1

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

Re: Noob in Python. Problem with fairly simple test case

[Rick Johnson]

On Friday, July 17, 2015 at 1:38:52 AM UTC-5, Steven D'Aprano wrote:
> 75% or 90% is not a "vast majority". Vast majority implies more than 99%.
> 
> But regardless of the precise meaning of "vast", if you want to dismiss one
> in four people (25%) or one in ten (10%) as inconsequential, then you've
> got some serious issues.

My estimate was *CONSERVATIVE* Steven. Read my words:
"EDUCATED GUESS". Unlike you, I'm not going to falsify the
numbers just to win an argument. I feel very strongly about
the 75%, even though i know the percentage is much higher.

> You can't "risk" the upgrade? What precisely are you afraid of?

Simple. I don't want to waste even a second of time
debugging old code that has been bug free for years. I would
rather spend that time writing new code. Productivity is
important to "some" of us Steven!

And don't drag out that old cliche about how running 2to3 is
the path to lands of "milk and honey". I call BS! With the
nonrestrictive typing of Python a bug can be hidden from even
the best testing methodology. Why would i risk exception hell
just to please you? I don't make my decisions based on your,
or the BDFL's, opinions of what is best for me. Heck, i
don't make my decisions based on what "might" be good for
the Python community. MY CODE! My RULES! GOT IT?

> That's nonsense. Spinning tires implies no forward motion.
> Python 3 usage is *certainly* moving forward: we've gone
> from the situation in 2008 of nobody using it, to the
> current situation where there's lots of activity around
> it:

How much of that is purely hype? Remember the explosion of
Python usage *BEFORE* Python3? However, there
has been a steady decline of Python usage since.

> students learning on Python 3, 

You act as if *EVERY* student that ever uses Python will
continue using Python forever, and *ONLY* Python! When in
fact, Python is mostly a stepping stone for CS-101 students
on their path to real languages like C, Java, DHTML, and the
APIs of the various mobile platforms. *THIS* is where code is
written to solve real life problems. *THIS* is where code
directly interacts with the *VAST MAJORITY* (yeah i said it!)
of humans on this planet to get stuff done! But where's Python? 

Oh, i know, it's stuck on my desktop. @_@

PYTHON IS A ONE TRICK PONY!

> My guess is, the rate of Python 3 adoption is going to hit
> the tipping point in 2 or 3 years, after which time it
> will be *very* rapid.

THE INTERNET WILL REMEMBER YOUR PREDICTION!

A lot can happen in 2-3 years that may render Python
obsolete (and your blabbing about 2020, really?).  My
prediction is that Python will never recover from this
backward compatibility issue. And sadly, Python2 had been
gaining stong momentum before Python3 arrived.

The code break was the first blow, and the evolving
technologies will be the final blow. Desktops computers are
becoming obsolete, and mobile platforms are the future. This
train has long since departed the station.

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

Need Help w. Getting the Eclipse Python Add-On.

[Steve Burrus]

I Need immediate Help w. Getting the Eclipse Python Add-On. I looked all around 
the Eclipse website to try to get this but didn't see the add-on for this. Can 
someone please help me to find it? Thanx.

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

Re: Need Help w. Getting the Eclipse Python Add-On.

[Jerry Hill]

On Fri, Jul 17, 2015 at 2:22 PM, Steve Burrus  wrote:
> I Need immediate Help w. Getting the Eclipse Python Add-On. I looked all 
> around the Eclipse website to try to get this but didn't see the add-on for 
> this. Can someone please help me to find it? Thanx.

I think you're looking for PyDev: http://www.pydev.org/

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

Re: Need Help w. Getting the Eclipse Python Add-On.

[Emile van Sebille]

On 7/17/2015 11:22 AM, Steve Burrus wrote:

I Need immediate Help w. Getting the Eclipse Python Add-On. I looked all around 
the Eclipse website to try to get this but didn't see the add-on for this. Can 
someone please help me to find it? Thanx.


Googling 'python ecplise' certainly yields a lot of apparently valid 
links -- you might have better luck starting with a tutorial -- see 
perhaps http://www.vogella.com/tutorials/Python/article.html gets you 
further down the road.


Emile






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

tkinter resize question

[nickgeovanis]

Resizing a tkinter window which contains a frame which contains a button 
widget, will not change the current size of the window, frame or button as 
recorded in their height and width attributes (at least not if they are 
resizable). What is the correct way to detect their current size?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Need assistance

[Mark Lawrence]

On 17/07/2015 17:40, Rob Gaddi wrote:

On Thu, 16 Jul 2015 19:15:38 -0700, craig.sirna wrote:


I need help writing a homework program.

I'll write it, but I can't figure out how to incorporate what I have
read in the book to work in code.

The assignment wants us to take a users first, middle and last name in a
single input ( name=('enter your full name: )).

Then we must display the full name rearranged in Last, First Middle
order.

I tried to use the search function in Python to locate any spaces in the
input. It spot back the index 5 (I used Craig Daniel Sirna)

That is correct for the first space, but I can't figure out how to get
it to continue to the next space.

The indexing process is also a bit confusingto me.

I get that I can use len(fullName) to set the length of the index, and
how the index is counted, but after that I'm lost.

I have emailed my professor a few times, but haven't gotten a
response.(online course)

Any help would be greatly appreciated.


1) Use the interactive console.  Set x = 'Craig Daniel Sirna' and play
with indexing and slicing it until you really internalize what they
mean.  x[3], x[-3], x[0:10], x[0:-1].  It's not actually relevant to the
problem at hand, but right now is the time in your education to get
indexing down cold; skimp on it now and you'll pay for it forever.
Should take you about 5 minutes.


I'll throw in something to emphasize a major difference between indexing 
and slicing.


>>> x = 'Craig Daniel Sirna'
>>> x[100]
Traceback (most recent call last):
  File "", line 1, in 
IndexError: string index out of range
>>> x[100:]
''
>>> x[:100]
'Craig Daniel Sirna'



2) https://docs.python.org/3/library/stdtypes.html#string-methods
You can do what you're trying to do, but you're swinging a hammer with a
powered nailgun at your feet.  Search is an inefficient way to try to
split a string into parts based on a delimiter.



Inefficient I don't know about, and mostly don't care about either, but 
certainly not the cleanest way to code, at least IMHO.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: tkinter resize question

[nickgeovanis]

On Friday, July 17, 2015 at 1:53:19 PM UTC-5, nickge...@gmail.com wrote:
> Resizing a tkinter window which contains a frame which contains a button 
> widget, will not change the current size of the window, frame or button as 
> recorded in their height and width attributes (at least not if they are 
> resizable). What is the correct way to detect their current size?

Ok, partially answering my own question:
The geometry of the window will change (win.geometry()), but the changes do not 
appear to "propagate" to the retrieved width/height of the child widgets, 
frames, etc. Or am I incorrect with this?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A new module for performing tail-call elimination

[Terry Reedy]

On 7/16/2015 3:45 PM, Marko Rauhamaa wrote:


Nobody seemed to notice that I just posted a fairly typical tail call
function:


Because non-recursive tail calls are completely normal. Example:
return len(self.children)

Even tail operations like
return a + b
are tail calls if rewritten as
return a.__add__(b)
(usually but not always equivalent) or rewritten as
return operator.add(a, b)
(always equivalent) or compiled by an implementation as an equivalent 
internal function call.


It happens to be that CPython implements calls to symbol operator 
functions by putting the bodies of such functions into a C switch inside 
a while loop.  It this compiles operator symbols into bytecodes that 
cause a jump to the corresponding code.


--
Terry Jan Reedy

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

Re: tkinter resize question

[Russell Owen]

On 7/17/15 12:17 PM, nickgeova...@gmail.com wrote:

On Friday, July 17, 2015 at 1:53:19 PM UTC-5, nickge...@gmail.com wrote:

Resizing a tkinter window which contains a frame which contains a button 
widget, will not change the current size of the window, frame or button as 
recorded in their height and width attributes (at least not if they are 
resizable). What is the correct way to detect their current size?


Ok, partially answering my own question:
The geometry of the window will change (win.geometry()), but the changes do not appear to 
"propagate" to the retrieved width/height of the child widgets, frames, etc. Or 
am I incorrect with this?


I'm not seeing it. If I try the following script I see that resizing the 
widget does update frame.winfo_width() and winfo_height. (I also see 
that the requested width and height are ignored; you can omit those).


-- Russell


#!/usr/bin/env python
import Tkinter
root = Tkinter.Tk()

frame = Tkinter.Frame(root, width=100, height=50)
frame.pack(expand=True, fill="both")
def doReport(*args):
print "frame actualwidth=%s, height=%s" % (frame.winfo_width(), 
frame.winfo_height())
print "frame requested width=%s, height=%s" % 
(frame.winfo_reqwidth(), frame.winfo_reqheight())

button = Tkinter.Button(frame, text="Report", command=doReport)
button.pack()

root.mainloop()


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

Re: tkinter resize question

[Rick Johnson]

On Friday, July 17, 2015 at 2:52:56 PM UTC-5, Russell Owen wrote:

> I'm not seeing it. If I try the following script I see
> that resizing the widget does update frame.winfo_width()
> and winfo_height. (I also see that the requested width and
> height are ignored; you can omit those).

I wonder if the OP is trying to query the sizes from inside
an event handler? Hmm. But since he failed to explain the problem
coherently, and also failed to provide a code sample, i'm
not willing to exert any effort beyond that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Terry Reedy]

On 7/17/2015 7:43 AM, Antoon Pardon wrote:

On 07/17/2015 01:05 PM, Chris Angelico wrote:



def gen():
 yield stuff
 yield more stuff

for stuff in gen():
 bomb with exception

The error didn't happen in the generator, so I wouldn't expect to see
it in the traceback.


Yes something like that. And I wouldn't expect it either but if it
is not present, is it because nobody thought about it or because it
is a bad idea or an idea difficult to implement?


There's still room for the cause of an error to
not be in the traceback; imagine, for instance, a function that
populates a concrete list, and then you iterate over the list. If that
function sticks a None into the list and the subsequent processing is
expecting all strings, that's going to bomb, but then you have to
figure out where the None came from. If the traceback could include
that, it'd be great, but some things aren't possible.


Sure, but in this case, the generator is still active.


No more than any other object sitting around inactive. Calling a 
generator function like gen above returns a generator with the generator 
function, in a suspended inactive state, attached as an attribute.  When 
the generator.__next__ function is called, it activates its instance of 
the generator function, which suspends itself again after yielding 
something.  At the point of the exception above, the generator next 
function has returned.  There could be multiple generators with 
suspended generator functions sitting around.  For instance:


def f():
for tup in zip(gf0, gf1, gf2, gf3, gf4, gf5):
a = tup[6]  # whoops, IndexError


--
Terry Jan Reedy

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

Re: Noob in Python. Problem with fairly simple test case

[Laura Creighton]

I think kivy is doing a very nice job of python-on-the-mobile.
Have you looked?  Please do not rant at me, just tell me what you
think.

Laura

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

Re: A new module for performing tail-call elimination

[Marko Rauhamaa]

Terry Reedy :

> On 7/16/2015 3:45 PM, Marko Rauhamaa wrote:
>> Nobody seemed to notice that I just posted a fairly typical tail call
>> function:
>
> Because non-recursive tail calls are completely normal.

I don't know how recursion makes a difference but that one did happen to
be recursive. It could easily have been replaced with a while loop but
there were good aesthetic reasons to leave it recursive.


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

Python Requirements

[Luke Harrison]

> Dear Python-List
> 
> As part of my A2 Computing coursework, I need to program a solution using
> Python 3.4. I also need to document the minimum requirements to run Python
> 3.4 on a Windows machine, including minimum RAM, minimum processing power,
> minimum hard disk space and monitor resolution.
> 
> I have searched the Python forums and website, but I was unable to find
> these requirements.
> 
> Could you please send me a copy of these requirements for use in my
> coursework?
> 
> Thank you for your response in advance,
> 
> Luke Harrison
> A2 Computing Student

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

Parsing and displaying C structs in a semi-intelligent way.

[Anders Wegge Keller]

 In my day job, we have a large code base of mostly identical projects, each
with their own customizations. The customizations can be a real pain
sometimes. Especially when debugging binary data. The interesting part of
the binary dumps are most often the stuff that are tweaked from project to
project. The prime suspect is a structure like this:

typedef struct
{
bytenext ;  /* Index to next wedge  */
byteflags ; /* ricd-control flags   */
wordalt [MAX_alt] ; /* Alternative wedges   */
...
} ConvResult ;

typedef struct
{
bytestate ; /* UCART_ (see cart.h)  */
wordheadcart ;  /* Cart number for header cart  */
ConvResult  conv ;
...
} cartUTable_t ;

 The actual structure with substructures are much larger. This structure
contains all the information used when sorting stuff[1]. For historical
reasons, the data is dumped to a binary file at the end of the items
life-cycle. We do have a debugging tool, that reads an in-house file format
specifying the members of the structure, and how to display them. However,
updating this description is error-prone, and just about as funny as waiting
for the Norwegian Blue to fly out over the fiords. So most often it's either
not done, or is unusable. 

 To clean up this mess, I've devised a cunning plan, involving a C-parser,
that can write a structure definition as XML. Reading this is simple enough,
and going from that to a format string for struct.unpack() is mostly
trivial. Except for the arrays of some C-type, that happens to be something
else than an array of char. Due to the normal use case[2] of dumping this
binary data, I need to get the parsed data munged into a form, that can be
put into a namedtuple as single member, even when I have an array of
(typical) six conv.alt values. I'm getting stuck with the limitations of
struct and namedtuple. While inheriting either of them to get the job done,
seem to be feasible, I still feel that I somehow should be able to do
something "list comprehension"-ish, to avoid going there. I just can't see
the light.

(Thank you for reading all the way to here!)


1. Luggage, parcels, shop replenishments ... In short: mostly rectangular
   things that has a barcode attached.

2. Random ordering, not displaying all members, and only a part of the
   arrays.

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

Re: Python Requirements

[Chris Angelico]

On Sat, Jul 18, 2015 at 7:37 AM, Luke Harrison  wrote:
> As part of my A2 Computing coursework, I need to program a solution using
>
> Python 3.4. I also need to document the minimum requirements to run Python
>
> 3.4 on a Windows machine, including minimum RAM, minimum processing power,
>
> minimum hard disk space and monitor resolution.

Simple answer: If it's capable of running a modern Windows, it's
capable of running Python. There's no screen resolution requirements,
and the RAM, CPU, and HD requirements depend more on what you do with
Python than on the language itself. The easiest way to find out is to
try it - grab the installer, plop it onto a system, see how much less
disk space you have. Then start running code and see how efficient it
is. There's a world of difference between the RAM/CPU requirements of
"Hello, world" and a program that does video processing, and that's
true regardless of the language.

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

Re: Noob in Python. Problem with fairly simple test case

[Mark Lawrence]

On 17/07/2015 21:38, Laura Creighton wrote:

I think kivy is doing a very nice job of python-on-the-mobile.
Have you looked?  Please do not rant at me, just tell me what you
think.

Laura



At least rr occasionally comes out with something useful, usually WRT 
tkinter.  He's in the bottom division when compared to the RUE, who is 
still managing to get onto gg with his complete nonsense.  I'll admit I 
enjoy tripping over there just to report him.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: tkinter resize question

[nickgeovanis]

On Friday, July 17, 2015 at 2:52:56 PM UTC-5, Russell Owen wrote:
> On 7/17/15 12:17 PM, nickgeova...@gmail.com wrote:
> > On Friday, July 17, 2015 at 1:53:19 PM UTC-5, nickge...@gmail.com wrote:
> >> Resizing a tkinter window which contains a frame which contains a button 
> >> widget, will not change the current size of the window, frame or button as 
> >> recorded in their height and width attributes (at least not if they are 
> >> resizable). What is the correct way to detect their current size?
> >
> > Ok, partially answering my own question:
> > The geometry of the window will change (win.geometry()), but the changes do 
> > not appear to "propagate" to the retrieved width/height of the child 
> > widgets, frames, etc. Or am I incorrect with this?
> 
> I'm not seeing it. If I try the following script I see that resizing the 
> widget does update frame.winfo_width() and winfo_height. (I also see 
> that the requested width and height are ignored; you can omit those).
> 
> -- Russell
> 
> 
> #!/usr/bin/env python
> import Tkinter
> root = Tkinter.Tk()
> 
> frame = Tkinter.Frame(root, width=100, height=50)
> frame.pack(expand=True, fill="both")
> def doReport(*args):
>  print "frame actualwidth=%s, height=%s" % (frame.winfo_width(), 
> frame.winfo_height())
>  print "frame requested width=%s, height=%s" % 
> (frame.winfo_reqwidth(), frame.winfo_reqheight())
> button = Tkinter.Button(frame, text="Report", command=doReport)
> button.pack()
> 
> root.mainloop()

So my mistake was, rather than calling frame.winfo_height() or winfo_width() as 
you've done, instead checking frame["width"] and frame["height"]. Which retain 
their original values regardless of actual size AFAICS. If you do the same on 
the button, I think you'll find the same (non?)issue. 

I don't think I've seen the "winfo_optioname()" construct in the python-side 
doc. For example Sec 25.1.6.1 "Setting Options" in the tkinter chapter of the 
standard python Library Reference doesn't mention it or anything syntactically 
similar. I'm sure the usual disclaimer "see the tcl/tk docs" applies, but this 
seems more than a detail to me. Thanks for your help...Nick
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Noob in Python. Problem with fairly simple test case

[Terry Reedy]

On 7/17/2015 12:15 AM, Rick Johnson wrote:

On Thursday, July 16, 2015 at 9:44:56 PM UTC-5, Steven D'Aprano wrote:

[...] My take from all this is that overall, Python 3
take-up is probably > around 10% of all Python users,


All that rambling just to agree with me? My educated guess
is a minimum of 75% still using Python2.x.


I would call that a strong majority.


But i'll take your 90% because it makes my argument stronger! O:-D


Unlike Chris, I would see that as a 'vast majority'.

But these relative numbers are, as near as I can tell, restricted to the 
english-speaking world, perhaps extended to the latin-1 based world. 
Anyone who wants unicode identifiers must use Python 3 (or a translated 
Python like ChinesePython).  Anyone seriously working with Unicode will 
find 3.3+ more pleasant, if not required (especially on Windows).


On Amazon, the first hit for 'Japanese Python' is Dive into Python 3 
(Japanese edition).  As near as I can tell, there is no Japanese edition 
for the original Dive into Python (2).  As I remember, half the Python 
books I saw in Japan *3 years ago* were for Python 3.


Overall, I suspect that Python 3 penetration is greater in Asia.

Rick, I only care about porting of public libraries.  Leave your private 
code in Python 2.  Continue writing new code in Python 2 if you wish.  I 
only object to those who pressure others to not port to or writes in 
Python 3.


If you want to help 2.7 become better, we need people test and backport 
patches to 2.7. Since 2.x bugs me as much as 3.x seems to bug you, I am 
considering not backporting until someone volunteers to help.


Now my question for you or anyone else: If the vast majority of Python 
programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs 
so scarce?  Does they all consider it perfect (or sufficient) as is? 
Should the core developers who do not personally use 2.7 stop 
backporting, because no one cares if they do?


--
Terry Jan Reedy

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

Re: tkinter resize question

[Terry Reedy]

On 7/17/2015 2:53 PM, nickgeova...@gmail.com wrote:

Resizing a tkinter window which contains a frame which contains a
button widget, will not change the current size of the window, frame
or button as recorded in their height and width attributes (at least
not if they are resizable).


Post the code and experiments performed that leads you to believe the above.

> What is the correct way to detect their current size?

It is hard to fix code not posted.

--
Terry Jan Reedy

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

Re: Noob in Python. Problem with fairly simple test case

[Emile van Sebille]

On 7/17/2015 3:45 PM, Terry Reedy wrote:


Now my question for you or anyone else: If the vast majority of Python
programmers are focused on 2.7,


I consider myself in this group.


why are volunteers to help fix 2.7 bugs so scarce?


perhaps the bugs that are show stoppers are providing the impetus to 
move forward to 3.x rather than fix?  This may be an argument to stop 
back-porting fixes.  (security bugs being the exception)



Does they all consider it perfect (or sufficient) as is?


I have a number of one-off projects in place and running without issues 
on python versions all the way back to probably 1.52 (it's turtles all 
the way down)  In all cases, the python version is perfect (or 
sufficient) as it sits.  I do continue to support the applications and 
find myself writing mostly in some common core level of 2.x.



Should the core developers who do not personally use 2.7 stop
backporting, because no one cares if they do?


That'd work for me.  I'm not looking to upgrade the python versions of 
functioning productive code.  Of course, neither are my customers 
looking to pay for me to f*ck^h^h^h^hupgrade up their non-buggy systems.


Emile





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

Re: Proposed keyword to transfer control to another function

[Cameron Simpson]

On 17Jul2015 20:43, Chris Angelico  wrote:

On Fri, Jul 17, 2015 at 5:17 PM, Antoon Pardon
 wrote:

On 07/17/2015 01:46 AM, Chris Angelico wrote:

Open for bikeshedding: What should the keyword be? We can't use
"exec", which would match Unix and shell usage, because it's already
used in a rather different sense in Python. Current candidates:
"transfer", "goto", "recurse", and anything else you suggest.


I propose the combination "return from". I think it is similar enough
with "yield from" to justify this and it also won't need an extra
keyword, so no programs will be broken because they used "transfer",
"goto" or whatever other new keyword as an identifier.



Oooh I like this. The parallel makes sense, and as you say, no new
keyword. Yes, "return from" is my new preferred command!


+1

Cheers,
Cameron Simpson 

A pessimist is an optimist in full possession of the facts.
--
https://mail.python.org/mailman/listinfo/python-list

Re: A new module for performing tail-call elimination

[Terry Reedy]

On 7/17/2015 4:55 PM, Marko Rauhamaa wrote:

Terry Reedy :


On 7/16/2015 3:45 PM, Marko Rauhamaa wrote:

Nobody seemed to notice that I just posted a fairly typical tail call
function:


Because non-recursive tail calls are completely normal.


I don't know how recursion makes a difference


There are two extremely important differences:
1. Direct recursion calls the function that contains the call.  This is 
what allows replacement of tail recursion with a loop within the same 
function.
2. Almost all problems with stack overflow are due to recursion, whether 
at the tail or within the body of a code block. Such problems are nearly 
always with linear recursion (one recursive call per call until the base 
case).  Problems with branching recursion (multiple recursive calls per 
call) are rare except for very deep trees and  graphs.



but that one did happen to be recursive.


Not directly, as needed for loop conversion.

class X:  # omitted from original but needed below
def setvalue(self, keyseq, value, offset=0):
...
child.setvalue(keyseq, value, offset + 1)

child.setvalue is a new callable bound method object, call it 'bm', that 
is different from the setvalue function. This tail call is not a tail 
recursive call. The standard conversion of adding a while loop and 
replacing the tail call with the assignment in the call, in this case 
'offset = offset+1' will not work.



It could easily have been replaced with a while loop


Given the equality stated below, then yes.
child.setvalue(*args) == bm(*args) calls (in 3.x)
bm.__func__(bm.__self__, *args)
If type(child) == type(self) == X, then bm.func == X.setvalue
and the indirect call is the same as
X.setvalue(child, keyseq, value, offset + 1)
making the bound method call indirectly recursive.
If we replace the bound method call in setvalue with the call to 
setvalue itself, then we have a tail recursive call and can do the 
standard replacement to get:


class X
def setvalue(self, keyseq, value, offset=0):
while True:
...
# child.setvalue(keyseq, value, offset + 1)
offset += 1
self = child

If children are not always instances of type(self), as when a tree has 
separate Node and Leaf classes, then recursive calls to Node instances 
must be separated from non-recursive Leaf calls before replacing the 
recursive calls.


Having a good reason to rebind the first parameter within methods, as 
above, is a good reason to not hide it (as some have proposed).



but there were good aesthetic reasons to leave it recursive.


Once one learns that looping and recursive calls are two ways of doing 
the same thing -- repeatedly executing a block of code with altered 
inputs, then the aesthetic reasons are purely aesthetic.


I personally would probably initially write and test setvalue with 
recursion.  If I were releasing it for others to use in production code 
(where aesthetics no longer break ties between equivalent correct 
implementations), I would do the conversion to avoid possible stack 
overflows.  For cases like this, where only some parameters are rebound, 
I might leave the original tail call in a comment as documentation, as I 
did above.


--
Terry Jan Reedy

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

Re: A new module for performing tail-call elimination

[Chris Angelico]

On Sat, Jul 18, 2015 at 10:40 AM, Terry Reedy  wrote:
> If children are not always instances of type(self), as when a tree has
> separate Node and Leaf classes, then recursive calls to Node instances must
> be separated from non-recursive Leaf calls before replacing the recursive
> calls.

More serious concern: If it's possible for one of the children to be
an arbitrary subclass of that type, it could have overridden the
setvalue method. To maintain the expectations, you absolutely have to
do the full lookup and pass the message down the chain.

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

Re: Need assistance

[Denis McMahon]

On Thu, 16 Jul 2015 19:15:38 -0700, craig.sirna wrote:

> The assignment wants us to take a users first, middle and last name in a
> single input ( name=('enter your full name: )).
> 
> Then we must display the full name rearranged in Last, First Middle
> order.

To generate a list of words from a string, split the string up on the 
spaces between words. See the split method of strings.

Having a list of words, get a copy of the list in reverse order. See the 
reversed function (and maybe the list function).

Note - reversed returns an iterable, list will convert the iterable to a 
list.

To join the elements of a list into a string, see the join method of 
strings.

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter resize question

[Terry Reedy]

On 7/17/2015 6:42 PM, nickgeova...@gmail.com wrote:


I don't think I've seen the "winfo_optioname()" construct in the
python-side doc. For example Sec 25.1.6.1 "Setting Options" in the
tkinter chapter of the standard python Library Reference doesn't
mention it or anything syntactically similar.


The docs are incomplete.


I'm sure the usual
disclaimer "see the tcl/tk docs" applies, but this seems more than a
detail to me. Thanks for your help...Nick


Better yet, bookmark this tkinter reference (which I believe is 
mentioned at the top of the doc). It is only missing stuff new in 8.6.

http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html
The winfo functions are included in 26 Universal widget methods.

http://effbot.org/tkinterbook/
has some worked out examples. There is also a lot on Stackoverflow, 
which has a tkinter tag.


--
Terry Jan Reedy

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

Re: tkinter resize question

[nickgeovanis]

On Friday, July 17, 2015 at 5:55:19 PM UTC-5, Terry Reedy wrote:
> On 7/17/2015 2:53 PM, nickgeova...@gmail.com wrote:
> > Resizing a tkinter window which contains a frame which contains a
> > button widget, will not change the current size of the window, frame
> > or button as recorded in their height and width attributes (at least
> > not if they are resizable).
> 
> Post the code and experiments performed that leads you to believe the above.

It's really boring but here you are:

[ngeo@localhost src]$ python3
Python 3.4.2 (default, Dec 20 2014, 13:53:33) 
[GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> win=tkinter.Tk()
>>> frame=tkinter.Frame(win, bg="blue", width=200, height=200)
>>> butt1=tkinter.Button(fg="green", bg="black")
>>> frame.grid()
>>> butt1.grid()
>>> butt1["width"]
0
>>> butt1["height"]
0
>>> win["width"]
0
>>> win["height"]
0

Needless to say the button has appeared and has non-zero size.

>  > What is the correct way to detect their current size?
> 
> It is hard to fix code not posted.

Just a question from first principles: Find a widget's current size.
But the code example posted showed a working way to do the same thing.
Unfortunately requiring a function call, and not in the doc online AFAICS 
butdoc is doc.
 
> Terry Jan Reedy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A new module for performing tail-call elimination

[Paul Rubin]

Chris Angelico  writes:
> My point was that I have yet to see anything that demands TCO and
> can't be algorithmically improved.

I don't think anyone claimed you can't simulate TCO with updateable
variables and a while loop.  TCO just sometimes lets you write some
things in a cleaner (in proponnets' view) style.

> The best so far has been a quicksort that uses TCO to guarantee a
> maximum on stack usage.

I actually thought the state machine example was more convincing.  Doing
that without TCO would have required some kind of explicit control loop
and a messy dispatch mechanism instead of direct chaining from one state
to the next.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed keyword to transfer control to another function

[Paul Rubin]

Chris Angelico  writes:
> # derived from Paul Rubin's example
> def quicksort(array, start, end):
>  midp = partition(array, start, end)

Heh, forgot to include the base case, as someone pointed out.  Oh well,
it's pseudocode, or something.

> transfer quicksort(array, midp+1, end)

Overall I like the idea but though it doesn't seem terribly important in
the scheme of things.  

I think the syntax has converged to "return from" which seems good to me.

> Note that this is incompatible with 'try' and 'with' blocks, and is

Maybe something can be done about that.

> Is there anything that I've missed out in speccing this up? I've a
> suspicion that this might turn out to be as complicated as 'yield
> from' in all its handling of edge cases.

Seems worthy of more thought.

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

Re: Proposed keyword to transfer control to another function

[Serhiy Storchaka]

On 17.07.15 02:46, Chris Angelico wrote:

Out of the lengthy thread on tail call optimization has come one broad
theory that might be of interest, so I'm spinning it off into its own
thread.

The concept is like the Unix exec[vlpe] family of functions: replace
the current stack frame with a new one. This can be used for explicit
tail recursion without repeated stack frames, or for a pre-check that
then disappears out of the stack. Like any other feature, it can be
misused to make debugging difficult, but among consenting adults,
hopefully it can be used sensibly.


I think there is no chance that this proposition will be accepted by 
Guido, because it makes debugging harder.



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

Re: tkinter resize question

[Terry Reedy]

On 7/17/2015 9:31 PM, nickgeova...@gmail.com wrote:

On Friday, July 17, 2015 at 5:55:19 PM UTC-5, Terry Reedy wrote:

On 7/17/2015 2:53 PM, nickgeova...@gmail.com wrote:

Resizing a tkinter window which contains a frame which contains a
button widget, will not change the current size of the window, frame
or button as recorded in their height and width attributes (at least
not if they are resizable).


Post the code and experiments performed that leads you to believe the above.


It's really boring but here you are:

[ngeo@localhost src]$ python3
Python 3.4.2 (default, Dec 20 2014, 13:53:33)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.

import tkinter
win=tkinter.Tk()
frame=tkinter.Frame(win, bg="blue", width=200, height=200)
butt1=tkinter.Button(fg="green", bg="black")
frame.grid()
butt1.grid()
butt1["width"]

0

butt1["height"]

0

win["width"]

0

win["height"]

0


I believe these configuration settings should be interpreted a 'initial 
size' (if not default) or 'desired size' or possibly min or max size, 
depending on the grid or pack settings.


--
Terry Jan Reedy

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