[issue32145] Wrong ExitStack Callback recipe

[Nick Coghlan]

Nick Coghlan  added the comment:

As per the comment at https://bugs.python.org/issue32445#msg309356, there's a 
bug in my suggested changes to `ExitStack.pop_all()`: the right method to call 
is ExitStack.push(), *not* ExitStack.callback() (the latter adds a wrapper 
function to make the signatures match, but our stored callbacks all already 
have the right signature).

I'm not too fussy about the details of the docstring, but we need to be careful 
about the guarantees we make to ExitStack subclasses: if the docstring implies 
that "target.push()" will always be called, then we need to limit the stack 
stealing behaviour to actual ExitStack instances (which may be a good idea 
anyway).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32445] Skip creating redundant wrapper functions in ExitStack.callback

[Nick Coghlan]

Nick Coghlan  added the comment:

Ah, you're right, I wasn't thinking clearly when I filed this - the correct 
public API method to transfer existing exit stack entries to a new stack would 
be "ExitStack.push()".

I'll make a note of that on the original issue.

--
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32478] Add tests for 'break' and 'return' inside 'finally' clause

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4958

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32452] Brackets and Parentheses used in an ambiguous way

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4957

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32452] Brackets and Parentheses used in an ambiguous way

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4956

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32452] Brackets and Parentheses used in an ambiguous way

[R. David Murray]

R. David Murray  added the comment:


New changeset f190eb59e60e2ae7a7cbd396458389a7a076e0d3 by R. David Murray 
(Emily Morehouse) in branch 'master':
bpo-32452: clarify term 'brackets' in generator tutorial (#5079)
https://github.com/python/cpython/commit/f190eb59e60e2ae7a7cbd396458389a7a076e0d3


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32478] Add tests for 'break' and 'return' inside 'finally' clause

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4955

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32478] Add tests for 'break' and 'return' inside 'finally' clause

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 7cc42c356b0dc5ad9eaa9392789e84bd4aa1c7de by Serhiy Storchaka in 
branch 'master':
bpo-32478: Add tests for 'break' and 'return' inside 'finally' clause. (#5078)
https://github.com/python/cpython/commit/7cc42c356b0dc5ad9eaa9392789e84bd4aa1c7de


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: stop prohibition of comp.lang.python ! D'Oliveiro should wear this as a badge of honour.

[breamoreboy]

On Monday, January 1, 2018 at 11:06:30 PM UTC, P. timoriensis wrote:
> >> stop prohibition of comp.lang.python !
> >>
> >> it is childish to do this prohibition business !
> >>
> >> don't you have spam filters ?
> > 
> > The prohibition part of the subject line is added by Lawrence D'Oliveiro 
> > when he posts on google groups as he's been banned from the mailing list.  
> > Most people won't see it until someone replies to his post via their email 
> > to the list.
> 
> > Mark Lawrence.
>  
> these cases are always the same: the censors in 99% of the cases are utterly 
> wrong.
> 
> 
> D'Oliveiro must be a good man, proof is here. 
> I know what to think about python-list censorship already.

Like the case of the guy who was banned as he was using the list to spread 
antisemitic drivel through his signatures?

If you don't like this facility you are perfectly welcome to leave and never 
come back.

--
Kindest regards.

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

Re: Copy-on-write friendly Python garbage collection (Posting On Python-List Prohibited)

[Niles Rogoff]

> Niles, if you want to claim wxjmfauth is right, you'll have to present
> some actual evidence.  He's claimed for years that Python's Unicode
> support is buggy (as he does here), without ever demonstrating a bug.
> We've long ago tired of trying to reason with him.
> 
> The tradeoffs of memory use for algorithmic complexity are well
> understood, and have been endlessly discussed. There is not an
> "obviously right" answer to how to make those tradeoffs.
> 
> --Ned.

Aah, I didn't know, I'm new here. I thought he was referring to UTF-16 
being inefficient, which is mostly what I was agreeing with.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32452] Brackets and Parentheses used in an ambiguous way

[Emily Morehouse]

Change by Emily Morehouse :


--
nosy: +emilyemorehouse

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32452] Brackets and Parentheses used in an ambiguous way

[Emily Morehouse]

Change by Emily Morehouse :


--
keywords: +patch
pull_requests: +4954
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: ✨✨ python 2018 wiki - a piece of cake ✨✨

[Chris Angelico]

On Tue, Jan 2, 2018 at 9:44 AM,   wrote:
> On Monday, January 1, 2018 at 2:54:26 PM UTC, S. I. wrote:
>> https://practical-scheme.net/wiliki/wiliki.cgi?python
>>
>> no register, no nothing !   just edit.
>>
>> ✨✨  python - a piece of cake  ✨✨
>>
>> just edit or enter acode.py   entry with
>>
>> {{{
>>
>> print(" oh yes, 2018   ")
>>
>> }}}
>
> From the link "Look at those scumbag admins over at the py wiki.", "what 
> utter pieces of s., man: 
> https://mail.python.org/pipermail/pydotorg-www/2017-June/004316.html;, "the 
> scum admins are waging another wiki war, follow it here: 
> https://mail.python.org/pipermail/pydotorg-www/;, "more Lemburg-type bs:" and 
> "Nothing but scum in the py wiki".  Were you the author of "How To Win 
> Friends And Influence People"?
>

Just FYI, the posts you're quoting here aren't making it to my inbox.
I believe they're getting blocked at the news/mail gateway (though it
could be elsewhere, for all I know). If you ignore them, we here in
the tame land of the mailing list would be cheerfully unaware of the
horrors ravaging the Wild West of the newsgroup.

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

[issue32453] shutil.rmtree can have O(n^2) performance on large dirs

[Niklas Hambüchen]

Niklas Hambüchen  added the comment:

A better location to view the whole coreutils thread is:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29921

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Tue, Jan 2, 2018 at 9:11 AM,   wrote:
> On Monday, January 1, 2018 at 9:35:06 PM UTC, Chris Angelico wrote:
>> On Tue, Jan 2, 2018 at 7:16 AM, Chris Green wrote:
>> > Dennis Lee Bieber wrote:
>> >>
>> >> Well... "break" does bypass the rest of the block, but it still 
>> >> exits
>> >> via the end of the block. I have a tendency to try for one "return" per
>> >> procedure (so I'm more likely to have an "if ...: break" then "if ...:
>> >> return").
>> >
>> > I have always tried to enforce 'only one return per function'.  If
>> > there are multiple returns it makes maintenance very difficult as
>> > 'clear up' code can get bypassed.
>> >
>>
>> Isn't that why try/finally exists? No matter how many 'return'
>> statements you have, there's always exceptions to bypass any naive
>> cleanup code; and no matter how many returns you have, 'finally'
>> blocks still execute before return.
>>
>> ChrisA
>
> What happened to context managers?
>

They're a way of wrapping up repeatedly-used try/finally blocks. The
try/finally construct is the underlying functionality. In any case,
the same behaviour can be used by either, so yes, if you have cleanup
code and you're using 'with x:' rather than try/finally, it still fits
into the same concept that I'm describing, and still guarantees that
the cleanup code is executed before return.

(Yes, I know it's possible to bypass finally blocks. But the methods
for doing so (eg hard-aborting) also bypass the actual return, so the
"before return" part is still valid. If you're doing things that
depend on cleanup outside the process, like deleting temporary files,
you'll need something more than try/finally. But in that case, there's
no other code layout that would help you anyway.)

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

Re: ✨✨ python 2018 wiki - a piece of cake ✨✨

[breamoreboy]

On Monday, January 1, 2018 at 2:54:26 PM UTC, S. I. wrote:
> https://practical-scheme.net/wiliki/wiliki.cgi?python
> 
> no register, no nothing !   just edit.
> 
> ✨✨  python - a piece of cake  ✨✨
> 
> just edit or enter acode.py   entry with 
>  
> {{{
> 
> print(" oh yes, 2018   ")
> 
> }}}

From the link "Look at those scumbag admins over at the py wiki.", "what utter 
pieces of s., man: 
https://mail.python.org/pipermail/pydotorg-www/2017-June/004316.html;, "the 
scum admins are waging another wiki war, follow it here: 
https://mail.python.org/pipermail/pydotorg-www/;, "more Lemburg-type bs:" and 
"Nothing but scum in the py wiki".  Were you the author of "How To Win Friends 
And Influence People"?

--
Kindest regards.

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

Re: stop prohibition of comp.lang.python !

[breamoreboy]

On Monday, January 1, 2018 at 3:00:19 PM UTC, S. I. wrote:
> stop prohibition of comp.lang.python !
> 
> it is childish to do this prohibition business !
> 
> don't you have spam filters ?

The prohibition part of the subject line is added by Lawrence D'Oliveiro when 
he posts on google groups as he's been banned from the mailing list.  Most 
people won't see it until someone replies to his post via their email to the 
list.

--
Kindest regards.

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

web fw performance with Erlang

[Wu Xi]

>> Well, a little implicitly. Pointing out Erlang superiority in a pythonic 
>> newsgroup is, of course, heresy.
> 
> Python is fourth in the latest TIOBE index, Erlang doesn't even make the top 
> 20, so in what way is it superior?
> 
> Python doesn't need Pinky and the Brain in its quest to take over the world.



Erlang is so fast, they had to ban erlang from competing here: 
https://www.techempower.com/benchmarks/#section=data-r14=ph=fortune

worst loser is the python framework of course
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ... (Posting On Python-List Prohibited)

[breamoreboy]

On Monday, January 1, 2018 at 9:28:01 PM UTC, Wu Xi wrote:
> > Blocking of spamming and trolling prevents oppression of people who want to 
> > use the list, funded by PSF, for its purpose, discussion of Python.
> 
> why are PSF funds privileged over anybody else's fund, which has zero 
> privilege?

Congratulations, after just a couple of days you're all ready pushing for a 
place in my dream team.

--
Kindest regards.

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

Re: ... (Posting On Python-List Prohibited)

[breamoreboy]

On Monday, January 1, 2018 at 10:21:15 PM UTC, P. timoriensis wrote:
> >>> Blocking of spamming and trolling prevents oppression of people who want 
> >>> to use the list, funded by PSF, for its purpose, discussion of Python.
> >>
> >> why are PSF funds privileged over anybody else's fund, which has zero 
> >> privilege?
> > 
> > Congratulations, after just a couple of days you're all ready pushing for a 
> > place in my dream team.
> 
> you sure would make for just another one of those self-appointed censors, who 
> won't react to legit questions, when they realize how dangerous they are.

I don't see a legitimate question, I see a completely stupid question.  The PSF 
pays the money, the PSF takes their choice.  If you don't like that you're 
perfectly free to use reddit, stackoverflow or any other forum.

--
Kindest regards.

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

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Monday, January 1, 2018 at 9:35:06 PM UTC, Chris Angelico wrote:
> On Tue, Jan 2, 2018 at 7:16 AM, Chris Green wrote:
> > Dennis Lee Bieber wrote:
> >>
> >> Well... "break" does bypass the rest of the block, but it still 
> >> exits
> >> via the end of the block. I have a tendency to try for one "return" per
> >> procedure (so I'm more likely to have an "if ...: break" then "if ...:
> >> return").
> >
> > I have always tried to enforce 'only one return per function'.  If
> > there are multiple returns it makes maintenance very difficult as
> > 'clear up' code can get bypassed.
> >
> 
> Isn't that why try/finally exists? No matter how many 'return'
> statements you have, there's always exceptions to bypass any naive
> cleanup code; and no matter how many returns you have, 'finally'
> blocks still execute before return.
> 
> ChrisA

What happened to context managers?

--
Kindest regards.

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

[issue32478] Add tests for 'break' and 'return' inside 'finally' clause

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +4953
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32478] Add tests for 'break' and 'return' inside 'finally' clause

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

'break' and 'return' are never used inside 'finally' clause in the stdlib. 
Therefore these cases are not covered by tests even implicitly. The proposed 
patch adds explicit tests for them.

'continue' inside 'finally' clause currently is prohibited (see issue1542451) 
and there are tests for this.

--
components: Tests
messages: 309352
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add tests for 'break' and 'return' inside 'finally' clause
type: enhancement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Humble Book Bundle: Python by Packt

[beliavsky--- via Python-list]

One can purchase the following Python books and videos published by Packt for 
$15 at https://www.humblebundle.com/books/python-by-packt-book-bundle for about 
the next two weeks.

Python Data Analysis Cookbook
Mastering Python, Second Edition
Learning Robotics using Python
Python Programming with Raspberry Pi
Web Development with Django Cookbook
Expert Python Programming, Second Edition
Learning Python Web Penetration Testing (Video)
Python Data Science Essentials, Second Edition
Learning Concurrency in Python
Python Data Structures and Algorithms
Beginning Python (Video)
Building RESTful Python Web Services
Mastering Python Networking
Artificial Intelligence with Python
Deep Learning with Python (Video)
Python Machine Learning Projects (Video)
Python Machine Learning
Python Microservices Development
Python Design Patterns (Video)
Software Architecture with Python
Modern Python Cookbook
Python High Performance, Second Edition
Python GUI Programming Cookbook, Second Edition
Mastering Python (Video)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32477] Move jumps optimization from the peepholer to the compiler

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +4952
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32477] Move jumps optimization from the peepholer to the compiler

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The proposed patch moves jumps optimization from the peepholer to the compiler. 
The optimization is performed for lists of instructions before generating 
concrete bytecode and is not restricted by the size of bytecode instructions. 
It allows to optimize more long chains of jumps.

This is a step to getting rid of the peepholer.

--
components: Interpreter Core
messages: 309351
nosy: benjamin.peterson, brett.cannon, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Move jumps optimization from the peepholer to the compiler
type: performance
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +4951

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: ... (Posting On Python-List Prohibited)

[Peter J. Holzer]

On 2018-01-01 21:27:00 +, Wu Xi wrote:
> > Blocking of spamming and trolling prevents oppression of people who
> > want to use the list, funded by PSF, for its purpose, discussion of
> > Python.
> 
> why are PSF funds privileged over anybody else's fund, which has zero
> privilege?

Because they pay for the server which runs the list. Their server, their
rules. If you set up a server which hosts a mailing list, a web forum,
or whatever, you get to decide ther rules for your server.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ... (Posting On Python-List Prohibited)

[Chris Angelico]

On Tue, Jan 2, 2018 at 8:27 AM, Wu Xi  wrote:
>
>> Blocking of spamming and trolling prevents oppression of people who want to 
>> use the list, funded by PSF, for its purpose, discussion of Python.
>
> why are PSF funds privileged over anybody else's fund, which has zero 
> privilege?

If you want to host your own mailing list on your own server, you're
welcome to. All the software you need is open source. (In fact, I can
and do host several mailing lists, though not for the discussion of
Python.)

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

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Tue, Jan 2, 2018 at 7:16 AM, Chris Green  wrote:
> Dennis Lee Bieber  wrote:
>>
>> Well... "break" does bypass the rest of the block, but it still exits
>> via the end of the block. I have a tendency to try for one "return" per
>> procedure (so I'm more likely to have an "if ...: break" then "if ...:
>> return").
>
> I have always tried to enforce 'only one return per function'.  If
> there are multiple returns it makes maintenance very difficult as
> 'clear up' code can get bypassed.
>

Isn't that why try/finally exists? No matter how many 'return'
statements you have, there's always exceptions to bypass any naive
cleanup code; and no matter how many returns you have, 'finally'
blocks still execute before return.

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

Re: ... (Posting On Python-List Prohibited)

[Wu Xi]

> Blocking of spamming and trolling prevents oppression of people who want to 
> use the list, funded by PSF, for its purpose, discussion of Python.

why are PSF funds privileged over anybody else's fund, which has zero privilege?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32474] argparse nargs should support string wrapped integers too

[R. David Murray]

R. David Murray  added the comment:

Agreed.  I don't think there is sufficient motivation for doing this, and there 
are downsides as Eric has pointed out.  Rejecting.

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: ... (Posting On Python-List Prohibited)

[Terry Reedy]

On 1/1/2018 1:28 PM, Wu Xi wrote:

on
https://mail.python.org/pipermail/python-list/2018-January/subject.html#start
which feeds intocomp.lang.python,
a lot of messages are missing. Appearantly there is some oppression scheme 
going on.


Blocking of spamming and trolling prevents oppression of people who want 
to use the list, funded by PSF, for its purpose, discussion of Python.


--
Terry Jan Reedy

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I just worked on it.

I meant Mark's PR :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Copy-on-write friendly Python garbage collection (Posting On Python-List Prohibited)

[Ned Batchelder]

On 1/1/18 1:49 PM, Niles Rogoff wrote:

On Mon, 01 Jan 2018 10:42:58 -0800, breamoreboy wrote:


On Monday, January 1, 2018 at 10:14:59 AM UTC, wxjm...@gmail.com wrote:

Le lundi 1 janvier 2018 08:35:53 UTC+1, Lawrence D’Oliveiro a écrit :

On Monday, January 1, 2018 at 7:52:48 AM UTC+13, Paul Rubin wrote:

I wonder if things would suffer if they tried a more aggressive
approach and ditched refcounting completely.

One thing that would suffer is Python’s well-behaved memory usage.
You would need to start imposing heap usage limits, like you do in
Java.

Memory:


sys.getsizeof('abcdefghij' + '$')

36

sys.getsizeof('abcdefghij' + '€')

60

sys.getsizeof(('abcdefghij' + '€').encode('utf-8'))

30

sys.getsizeof('abcdefghij' + '\U0001')

84

sys.getsizeof(('abcdefghij' + '\U0001').encode('utf-8'))

31



Performance:
"anti - utf-32"

Buggyness:
Better to not comment.

Python is the single language, which is presenting the opposite of what
Unicode.org offers on the side of memory *and* on the side of
performance, utf-8 *and* utf-32 !

Happy new year.

He's right though. I would encourage anyone interested to check out
http://utf8everywhere.org/

Niles, if you want to claim wxjmfauth is right, you'll have to present 
some actual evidence.  He's claimed for years that Python's Unicode 
support is buggy (as he does here), without ever demonstrating a bug.  
We've long ago tired of trying to reason with him.


The tradeoffs of memory use for algorithmic complexity are well 
understood, and have been endlessly discussed. There is not an 
"obviously right" answer to how to make those tradeoffs.


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

Re: Goto (Posting On Python-List Prohibited)

[Chris Green]

Dennis Lee Bieber  wrote:
> 
> Well... "break" does bypass the rest of the block, but it still exits
> via the end of the block. I have a tendency to try for one "return" per
> procedure (so I'm more likely to have an "if ...: break" then "if ...:
> return"). 

I have always tried to enforce 'only one return per function'.  If
there are multiple returns it makes maintenance very difficult as
'clear up' code can get bypassed.

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> It would be nice to know if it's able to fix the stack size issues as in the 
> following tests:

I just worked on it. See issue24340.

--
dependencies: +co_stacksize estimate can be highly off

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24340] co_stacksize estimate can be highly off

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Tests originally based on Antoine's tests added for PR 2827.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24340] co_stacksize estimate can be highly off

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

With PR 5076 the result of the above example is 10.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24340] co_stacksize estimate can be highly off

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +4950

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto (Posting On Python-List Prohibited)

[John Q Hacker]

Sorry, delete string "n't".  I mean that you would strcuture your code
with that architecture.

Hate that.

marxos

On 1/1/18, John Q Hacker  wrote:
>>> I don’t use gotos in C code. Why should it be “harder” in a higher-level
>>> language?
>>
>> Good for you.
>>
>> Looking at 14 million lines of Linux kernel sources, which are in C,
>> over 100,000 of them use 'goto'. About one every 120 lines.
>
> Most use of goto's implies a lack of understanding of the unseen
> architecture of the problem domain itself (otherwise, you wouldn't
> have structured your program with that architecture).  The only
> remaining use is optimization, and most of that is probably premature,
> as use of gotos *can* make things hard to understand, but using labels
> is a pretty happy medium.
>
> Marxos
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[John Q Hacker]

>> I don’t use gotos in C code. Why should it be “harder” in a higher-level
>> language?
>
> Good for you.
>
> Looking at 14 million lines of Linux kernel sources, which are in C,
> over 100,000 of them use 'goto'. About one every 120 lines.

Most use of goto's implies a lack of understanding of the unseen
architecture of the problem domain itself (otherwise, you wouldn't
have structured your program with that architecture).  The only
remaining use is optimization, and most of that is probably premature,
as use of gotos *can* make things hard to understand, but using labels
is a pretty happy medium.

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

[issue32474] argparse nargs should support string wrapped integers too

[Andrew Svetlov]

Andrew Svetlov  added the comment:

-1

--
nosy: +asvetlov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How to create a python extension module from a shared library?

[Etienne Robillard]

So far I found the SWIG method quite good. But I really think that I 
will try patching CFFI to use libclang natively.


Etienne


Le 2017-12-29 à 20:00, Etienne Robillard a écrit :

Hi all,

I would like to extend uWSGI by creating a CPython extension module 
for the libuwsgi.so shared library included in the distribution.


My goal is to use this automatically generated CPython module for 
extending uWSGI.


I have summarized my current approach here:

https://mail.python.org/pipermail/tutor/2017-December/112475.html

So far, I have tried to use CFFI and pycparser to generate the Python 
bindings, however CFFI and pycparser doesn't handle C directives like 
#include and #define.


I also attempted using clang to preprocess the "uwsgi.h" header found 
in the uWSGI distro with pycparser.parse_file() to generate a AST, 
however the generated AST object seems incorrect.


Is there any way to reflect a shared library into a CPython module?

I know that using "nm -D libuwsgi.so" I can get a list of available 
functions for this module. However, I have very little experience with 
ctypes and CFFI.


Do I need to modify CFFI to allow it to parse a C header with libclang?

I'm guessing CFFI/clang or ctypes should allow me to reflect the 
shared library, but I'm not sure about which method is the most 
appropriate.



What do you think?

Sincerely,

Etienne



--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

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

Re: Goto (Posting On Python-List Prohibited)

[From]

  




   (Posting On Python-List Prohibited)



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

Re: Copy-on-write friendly Python garbage collection

[breamoreboy]

On Monday, January 1, 2018 at 12:53:03 PM UTC, Wu Xi wrote:
> breamoreboy:
> > On Sunday, December 31, 2017 at 6:19:13 PM UTC, Wu Xi wrote:
> >> breamoreboy:
> >>> An interesting write up on something that is incorporated into Python 3.7 
> >>> https://engineering.instagram.com/copy-on-write-friendly-python-garbage-collection-ad6ed5233ddf
> >>
> >> Appearantly, Erlang is the way to go, when it comes to web frameworks.
> > 
> > What has that got to do with the subject of this thread?
> 
> Well, a little implicitly. Pointing out Erlang superiority in a pythonic 
> newsgroup is, of course, heresy.

Python is fourth in the latest TIOBE index, Erlang doesn't even make the top 
20, so in what way is it superior?

Python doesn't need Pinky and the Brain in its quest to take over the world.

--
Kindest regards.

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

[issue32476] Add concat functionality to ElementTree xpath find

[John Jolly]

New submission from John Jolly :

The current implementation of the xpath specification in ElementTree does not 
allow for predicates that may contain both an apostrophe and a quote. Either 
one or the other is allowed, but escaping (either string escaping using the 
backslash or html escaping) is not supported.

A simple solution would be to implement the xpath concat function for 
predicates. This would allow the combination of quote types in the predicate. 
Attached is a proposed patch for this fix.

--
components: Library (Lib)
files: etree-concat.patch
keywords: patch
messages: 309344
nosy: jjolly
priority: normal
severity: normal
status: open
title: Add concat functionality to ElementTree xpath find
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47360/etree-concat.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 15:06, From wrote:
   



 


(Posting On Python-List Prohibited)



 why ?



Huh?

I'm posting to the usenet group comp.lang.python (an off-topic reply to 
an off-topic remark, but it happens).


I've no idea what the prohibited part is about, if that's what you're 
posting about. But there have been dozens of other messages with the 
same subject.

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

Re: Scientific Python moving to Python 3 only.

[MRAB]

On 2018-01-01 06:10, Terry Reedy wrote:

https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst

Numpy people currently plan to stop adding features to their 2.7 branch
after Dec 31, 2018 and stop adding bug fixes to the last version
supporting 2.7 a year later, Dec 31, 2019.  It will remain available for
pip installation, and possible support by other (most likely commercial)
parties.

http://www.python3statement.org/
About 30 other projects, including other part of the python-science
stack, have 'pledged' to so something similar.

FTR, I'll be dropping support for the regex module on Python 2 at about 
the same time.


(In practice, there's a lot of code sharing with regex on Python 3, but 
if it's not a bug on Python 3, then it'll be "Won't fix".)

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

Re: Copy-on-write friendly Python garbage collection (Posting On Python-List Prohibited)

[Niles Rogoff]

On Mon, 01 Jan 2018 10:42:58 -0800, breamoreboy wrote:

> On Monday, January 1, 2018 at 10:14:59 AM UTC, wxjm...@gmail.com wrote:
>> Le lundi 1 janvier 2018 08:35:53 UTC+1, Lawrence D’Oliveiro a écrit :
>> > On Monday, January 1, 2018 at 7:52:48 AM UTC+13, Paul Rubin wrote:
>> > > I wonder if things would suffer if they tried a more aggressive
>> > > approach and ditched refcounting completely.
>> > 
>> > One thing that would suffer is Python’s well-behaved memory usage.
>> > You would need to start imposing heap usage limits, like you do in
>> > Java.
>> 
>> Memory:
>> 
>> >>> sys.getsizeof('abcdefghij' + '$')
>> 36
>> >>> sys.getsizeof('abcdefghij' + '€')
>> 60
>> >>> sys.getsizeof(('abcdefghij' + '€').encode('utf-8'))
>> 30
>> >>> sys.getsizeof('abcdefghij' + '\U0001')
>> 84
>> >>> sys.getsizeof(('abcdefghij' + '\U0001').encode('utf-8'))
>> 31
>> >>>
>> >>>
>> Performance:
>> "anti - utf-32"
>> 
>> Buggyness:
>> Better to not comment.
>> 
>> Python is the single language, which is presenting the opposite of what
>> Unicode.org offers on the side of memory *and* on the side of
>> performance, utf-8 *and* utf-32 !
>> 
>> Happy new year.
> 

He's right though. I would encourage anyone interested to check out 
http://utf8everywhere.org/
> Your usual drivel.  When are you going to stop banging this drum, you've
> done nothing else for the past five years?

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

[issue32416] Refactor and add new tests for the f_lineno setter

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 439ce8a93936d92e4f10765c482195a28e93ec76 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
bpo-32416: Add two new tests in test_sys_settrace. (GH-5072) (#5073)
https://github.com/python/cpython/commit/439ce8a93936d92e4f10765c482195a28e93ec76


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32416] Refactor and add new tests for the f_lineno setter

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 2de47ca109d0418c7c01e451b5614f748ad76ee9 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '2.7':
bpo-32416: Add two new tests in test_sys_settrace. (GH-5072) (#5074)
https://github.com/python/cpython/commit/2de47ca109d0418c7c01e451b5614f748ad76ee9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32474] argparse nargs should support string wrapped integers too

[Shubham Sharma]

Change by Shubham Sharma :


--
pull_requests: +4949

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

... (Posting On Python-List Prohibited)

[Wu Xi]

>>     (Posting On Python-List Prohibited)



>>  why ?


 
> I'm posting to the usenet group comp.lang.python (an off-topic reply to an 
> off-topic remark, but it happens).

> I've no idea what the prohibited part is about, if that's what you're posting 
> about. But there have been dozens of other messages with the same subject.



that's right. on 

https://mail.python.org/pipermail/python-list/2018-January/subject.html#start


which feeds intocomp.lang.python,

a lot of messages are missing. Appearantly there is some oppression scheme 
going on.



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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I took a quick look at Mark's PR.  The main thing going for it IMHO is that it 
produces simpler bytecode: it removes the complicated with/finally-related 
opcodes, while Serhiy's has non-trivial END_FINALLY and POP_FINALLY.

It would be nice to know if it's able to fix the stack size issues as in the 
following tests:
https://github.com/python/cpython/pull/5006/files?diff=unified#diff-dae68b96e8fdcb924e1ea46c31f51aec

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32416] Refactor and add new tests for the f_lineno setter

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4948

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32416] Refactor and add new tests for the f_lineno setter

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset e8ed96550c6aa9a1e39c36e67e892994e25e2c41 by Serhiy Storchaka in 
branch 'master':
bpo-32416: Add two new tests in test_sys_settrace. (#5072)
https://github.com/python/cpython/commit/e8ed96550c6aa9a1e39c36e67e892994e25e2c41


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32416] Refactor and add new tests for the f_lineno setter

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4947

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

New opcodes in PR 5071 look interesting, but I think it is better to leave this 
experiment for a separate issue.

Complexities of PRs (ignoring tests, documentation, and generated files):

PR 4682:
 Include/opcode.h  |  12 +-
 Lib/opcode.py |  21 +-
 Objects/frameobject.c | 241 -
 Objects/genobject.c   |  10 +-
 Python/ceval.c| 426 +++
 Python/compile.c  | 884 +---
 Python/peephole.c |  18 +-
 7 files changed, 979 insertions(+), 633 deletions(-)

PR 5006:
 Include/opcode.h  |   8 +-
 Lib/opcode.py |  11 +-
 Objects/frameobject.c | 203 -
 Objects/genobject.c   |  10 +-
 Python/ceval.c| 344 ---
 Python/compile.c  | 474 +---
 Python/peephole.c |  33 ++--
 7 files changed, 561 insertions(+), 522 deletions(-)

PR 5071:
 Include/frameobject.h |   5 +-
 Include/opcode.h  |  18 +-
 Lib/opcode.py |  25 +-
 Objects/frameobject.c | 224 ++-
 Objects/genobject.c   |  10 +-
 Python/ceval.c| 507 -
 Python/compile.c  | 681 +++-
 Python/peephole.c |  49 +---
 Python/wordcode_helpers.h |  33 ++-
 9 files changed, 827 insertions(+), 725 deletions(-)

PR 4682: +4 opcodes, -4 opcodes, and changed numerical values of 2 opcodes
PR 5006: +4 opcodes, -4 opcodes
PR 5071: +8 opcodes, -8 opcodes, and changed numerical value of 1 opcode

It looks to me that PR 5006 has the lowest complexity and is the most easy for 
reviewing.

I'm working on it since taking Antoine's PR 5 months ago.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix

[Michael Felt]

Michael Felt  added the comment:

There were changes made - I know not when - but OOT builds work now. This issue 
may be closed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 14:54, Peter J. Holzer wrote:

On 2017-12-30 11:07:56 -0500, Dennis Lee Bieber wrote:



Yes. I don't know any language which enforces "pure" structured
programming. They all have some constructs (goto, break, return,
exceptions, ...) to leave a block early. I don't think that invalidates
my point that the concept of structured programming predates Pascal.


Functional languages?

Some banish not only goto, but the concepts of assignments, and variables.

And even functions have to be pure with no side-effects, which makes I/O 
a problem.


They are really intent on making life difficult.

--
bartc

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

[issue28290] BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"

[Michael Felt]

Michael Felt  added the comment:

this was just feedback - and should probably be closed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32474] argparse nargs should support string wrapped integers too

[Eric V. Smith]

Change by Eric V. Smith :


--
versions:  -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt  added the comment:

As I was not responding properly (too verbose) - I'll reread the thread for the 
initial patch suggestion - and hope it still fits the current 'master'.

My apologies for the long silence on this.

--
nosy:  -aixto...@gmail.com

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32416] Refactor and add new tests for the f_lineno setter

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +4946

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Mark Shannon]

Mark Shannon  added the comment:

It shouldn't be a surprise that I have submitted a PR. The original patch was 
my work and a month ago I said I would update it over the Christmas break. 

To avoid "competing" PRs in future, simply asking before appropriating other 
peoples work would help. I've signed the CLA, so I don't think there are any 
legal issues with Serhiy's or Neil's PRs containing my code, but it does seem a 
bit presumptive.

Having said that, if someone can convince me that Serhiy's PR is better, then I 
have no problem with it being merged.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32475] Add ability to query number of buffered bytes available on buffered I/O

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Why don't you use BufferedReader.peek()?

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

So we now have three competing PRs... each of which is not trivial. It would be 
nice if somehow there could be some conciliation, or at least a synthetic 
comparison. I don't think I want to review all three proposals (and I already 
spent time reviewing previous versions of Serhiy's).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed

[Michael Felt]

Michael Felt  added the comment:

Did some additional research. The code can work asis when _ALL_SOURCE is 
undefined. Or, in other words - there does not have to be a variable syntax 
issue or separate code for AIX.

As you read this - please remember that since issue #32143 was 'resolved' AIX 
cannot compile.

* 
https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html

describes _ALL_SOURCE as a macro for AIX3.

Looking at AIX: /usr/include/sys/types.h - by undefining _ALL_SOURCE the 
typedefs in the header files are equivalent enough that the new code added for 
os.statvfs(path) is compiled by both gcc and xlc.

As examples (from Centos)
/usr/include/bits/typesizes.h:72:#define __FSID_T_TYPE  struct { int 
__val[2]; }

And from AIX:
 * /usr/include/sys/types.h
  +360  / * typedef for the File System Identifier (fsid).  This must correspond
  +361* to the "struct fsid" structure in _ALL_SOURCE below.
  +362* /
  +363  typedef struct fsid_t {
  +364  #ifdef __64BIT_KERNEL
  +365  unsigned long val[2];
  +366  #else  / * __64BIT_KERNEL * /
  +367  #ifdef _ALL_SOURCE
  +368  unsigned int val[2];
  +369  #else  / * _ALL_SOURCE * /
  +370  unsigned int __val[2];
  +371  #endif / * _ALL_SOURCE * /
  +372  #endif / * __64BIT_KERNEL * /
  +373  } fsid_t;
 */

(Note - a variation of the text above was in the pull request 
https://github.com/python/cpython/pull/4972. Per reviewer request - this is 
removed and a discussion is now open here.)

Thank you for your comments.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto (Posting On Python-List Prohibited)

[Peter J. Holzer]

On 2017-12-30 11:07:56 -0500, Dennis Lee Bieber wrote:
> On Sat, 30 Dec 2017 13:46:14 +0100, "Peter J. Holzer" 
> declaimed the following:
> 
> >I don't think this is correct. Structured programming is much older:
> >ALGOL 60 was already a block structured language and Dijkstra wrote
> >"goto considered harmful" in the late 1960s. Pascal appeared in 1970, C
> >in 1974. To me (who learned to program in BASIC on a CP/M machine), C
> >is very much a structured programming language. If structured
> >programming gained traction around 1980, it might even have been because
> >structured languages like C with good performance became widely
> >available.
> >
>   There is a slight difference between just being block structured and
> full structured programming (at the time "one-entry/one-exit per
> construct".

I'd say there is a rather big difference: One is a programming paradigm,
the other a syntactic aid for the former. You can do structured
programming in assembler (I did in BASIC), but it is a lot easier and
natural in a block-structured language. I wasn't present when ALGOL was
invented (I wasn't even born then), but I am sure that the inventors
shared much of the mindset of "structured programming" (although the
name may not yet have been invented).

> Even Pascal still had a GOTO statement,

Yes. I don't know any language which enforces "pure" structured
programming. They all have some constructs (goto, break, return,
exceptions, ...) to leave a block early. I don't think that invalidates
my point that the concept of structured programming predates Pascal.

> and flow-charts were still part of documentation at school.

We learned about them in the 80's, too (along with Nassi-Shneiderman
diagrams). And in fact I still use them sometimes (although more
frequently to document processes for humans than for computers).
(I don't use NS diagrams at all anymore: They have no advantages over
pseudo code for me.)

>   The /teaching/ of structured programming as a discipline didn't really
> show up until my final year in college (79-80) and the first few years at
> Lockheed

I can't comment on how wide-spread teaching of structured programming
was, since I am too young. But since Pascal was explicitely intended as
a teaching language for structured programming, there must have been at
least a few professors to teach it in the late 1960's.

> -- which was also a time period when such abominations as TEXTFOR,
> MORTRAN, and RATFOR were created to allow for doing structured programming
> in FORTRAN-IV

And regardless of the quality (or lack thereof) of these preprocessors
I'd argue that they were created (and used) because at the time many
programmers thought that structured programming was a good idea. 

Is there any mainstream (procedural) computer language invented after
1970 which doesn't try to encourage structured programming?

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter MP working like a charm

[Wu Xi]

Abdur-Rahmaan Janhangeer:
> it seems that the original poster's mail went missing
> 
> leugenpresse means lying press btw
> 
> weird
> 
> i doubt the author wanted to prank us by announcing i did this and that.
> 
> Abdur-Rahmaan Janhangeer,
> Mauritius
> abdurrahmaanjanhangeer.wordpress.com
> 
> On 31 Dec 2017 5:00 am, "Wu Xi"  wrote:
> 
>> from tkinter import *#I cant see



Lügen Presse = lying press , fake news makers - indeed.

Using a real news reader, changing the post's topic still keeps the posting 
chain intact. I hope ypu don't use soft not giving you that post concatenation 
feature.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Mr. Conway in 50 lines of code (Posting On Python-List Prohibited)

[Wu Xi]

the short versions are not equivalent, proggy won't work with them


> def neighbours(point):
>  x,y = point
>   
>  yield x + 1 , y
>  yield x - 1 , y
>  yield x , y + 1
>  yield x , y - 1 #this is proof that life can emerge 
> inside of computers and cellular automatons,
>   
>  yield x + 1 , y + 1 #and evolve through memory, attack 
> other cells and morph into toads, pulsars, etc..
>  yield x + 1 , y - 1
>  yield x - 1 , y + 1 #spray your memory with space alien 
> patterns and life evolution will start in your machine !
>  yield x - 1 , y - 1
>  
>  '''
>  for i in range(-1, 2) :
> for j in range(-1, 2) :
> if i != j :
> yield x + i, y + j
> 
>  '''
>  # yield from [(x+i, x+j) for i in [-1,1] for j in [-1,1]]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anaconda Navigator : Add App

[Ian]

Anaconda is v3.6


very 2017'ish by now... 


;-)

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

Re: you shortened it, but you broke it too... ;-)

[Ned Batchelder]

On 12/31/17 8:15 PM, Wu Xi wrote:

def neighbours(point):
  x,y = point
   
  yield x + 1 , y

  yield x - 1 , y
  yield x , y + 1
  yield x , y - 1 #this is proof that life can emerge 
inside of computers and cellular automatons,
   
  yield x + 1 , y + 1 #and evolve through memory, attack other cells and morph into toads, pulsars, etc..

  yield x + 1 , y - 1
  yield x - 1 , y + 1 #spray your memory with space alien 
patterns and life evolution will start in your machine !
  yield x - 1 , y - 1


This code correctly yields eight new coordinates
  
  '''

  for i in range(-1, 2) :
 for j in range(-1, 2) :
 if i != j :
 yield x + i, y + j

  '''


This code only yields six of the eight needed.

  # yield from [(x+i, x+j) for i in [-1,1] for j in [-1,1]]
  


This code only yields four!

Perhaps this is what you are looking for:

    def neighbors(point):
    x, y = point
    for dx in [-1, 0, 1]:
    for dy in [-1, 0, 1]:
    if dx == dy == 0:
    continue
    yield x + dx, y + dy


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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +4945

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: tkinter MP working like a charm - almost...

[Wu Xi]

from tkinter import * ; from tkinter import messagebox
import asyncio ,  random

async def one_url(url):  
""" This is a multi threaded tkinter demo where tasks run in the background 
and aim to not freeze the tk GUI, py v3.7"""
sec = random.randint(1, 8)
await asyncio.sleep(sec  )
return 'url: {}  took {}  seconds'.format(url, sec)

async def do_urls():   
""" Creating and starting 10 tasks. """
tasks   = [one_url(url)  for url  inrange(10)]
completed, pending = await asyncio.wait(tasks)
results = [task.result() for task incompleted]
print('\n'.join(results))

def do_nofreeze(): messagebox.showinfo(message='see, Tkinter is still 
responsive.')

def widgets(master):   Button(master, text='GUI Frozen?',   
command=do_nofreeze).pack()

def tk_update(interval): 
""" A production version of this should make it possible to cancel. 
However, when loop stops, updates will stop. T. Reedy"""
loop.call_later(  interval,  root.update  )
root.update()

if __name__ == '__main__':
root = Tk()
widgets(root)
loop = asyncio.get_event_loop()
tk_update(.05)
loop.run_until_complete(do_urls())  
#   wow! no call to  root.mainloop()  
anymore. somehow like in IDLE - but it freezes now :-( 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Copy-on-write friendly Python garbage collection

[Wu Xi]

breamore...@gmail.com:
> On Sunday, December 31, 2017 at 6:19:13 PM UTC, Wu Xi wrote:
>> breamoreboy:
>>> An interesting write up on something that is incorporated into Python 3.7 
>>> https://engineering.instagram.com/copy-on-write-friendly-python-garbage-collection-ad6ed5233ddf
>>
>> Appearantly, Erlang is the way to go, when it comes to web frameworks.
> 
> What has that got to do with the subject of this thread?

Well, a little implicitly. Pointing out Erlang superiority in a pythonic 
newsgroup is, of course, heresy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Sunday, December 31, 2017 at 6:56:16 PM UTC, bartc wrote:
> On 31/12/2017 17:01, breamoreboy wrote:
> 
> >Further I've never once in 17 years of using Python been tearing my hair out 
> >over the lack of goto
> 
> Neither have I over all the advanced features of Python I never use, and 
> for double that number of years.

I suggest that you steer well clear of all of Python's advanced features until 
you understand the Python philosophy as laid down in the Zen of Python.  
However I cannot see that happening as you seem to dispute everything about 
Python, flying in the face of any advice that you get from all the very 
experienced Pythonistas who frequent this place.  You must have access to the 
PSU's time machine if you've 34 years experience of Python as it hasn't been 
out that long.

> 
> Yet for some they will be as indispensable as they are incomprehensible 
> to others.

Let's all go back to machine code.

--
Kindest regards.

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

Re: Copy-on-write friendly Python garbage collection

[breamoreboy]

On Sunday, December 31, 2017 at 6:19:13 PM UTC, Wu Xi wrote:
> breamoreboy:
> > An interesting write up on something that is incorporated into Python 3.7 
> > https://engineering.instagram.com/copy-on-write-friendly-python-garbage-collection-ad6ed5233ddf
> 
> Appearantly, Erlang is the way to go, when it comes to web frameworks.

What has that got to do with the subject of this thread?

--
Kindest regards.

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

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 00:40, MRAB wrote:

On 2017-12-31 23:21, bartc wrote:


[Block delimiting]


proc fn2(int a)=

...

end

(or possibly "inline f123=").

[snip]

OT: if "case ... esac" and "if ... fi", why not "proc ... corp"? :-)


(I don't think Algol-68 used corp otherwise it might have been copied 
too. But I also have 'function', and 'noitcnuf' would be a bit much.


Anyway in this variation of the syntax, there is a choice of block endings.

So 'case' can be closed with 'end', 'endcase', 'end case' or 'esac'.

With loops like while-do, either 'while' or 'do' can be the keyword.

For some kinds of blocks, (...) can be used.

But there can't be no block ending as in Python; there has to be 
something. Indentation here is not significant.)


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

[issue32466] Fix missing test coverage for fractions.Fraction.__new__

[Mark Dickinson]

Mark Dickinson  added the comment:

I've retitled the issue to avoid confusion, since we're no longer proposing 
removing the _gcd function.

--
title: Remove fractions._gcd() -> Fix missing test coverage for 
fractions.Fraction.__new__

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32466] Remove fractions._gcd()

[Mark Dickinson]

Mark Dickinson  added the comment:

> the types in question were added to the numeric tower for gmpy 2.0.9 and 
> 2.1.0.

Ah, good to know. Thanks. I was using 2.0.8.

> * We're back to needing a test for the line in question.

Agreed. It's not currently covered, and with the current behaviour the line 
_is_ necessary.

> * We're eschewing the possibility of changing the behavior of 
> `fractions.Fraction` to force int numerator and denominator.

I think that's a separate issue from this one, and if you want to pursue it 
it's worth its own issue on the tracker. But there would need to be a good 
reason for deliberately changing the existing by-design behaviour.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32474] argparse nargs should support string wrapped integers too

[Shubham Sharma]

Change by Shubham Sharma :


--
keywords: +patch
pull_requests: +4944
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32475] Add ability to query number of buffered bytes available on buffered I/O

[Tim Savannah]

New submission from Tim Savannah :

Hello!

This is my first time submitting to Python bug tracker, so please bear with me 
if I miss/mess something.

So a little bit of relevant background, I'm an avid python developer with many 
open-source projects.

One of the projects I wrote and maintain is called "python-nonblock", which 
provides pure-python non-blocking I/O methods. It is available at:

https://github.com/kata198/python-nonblock


I'll only include the relevant details to this topic.

So, one of the features provided by the python-nonblock in the nonblock_read 
function. This allows you to read from a stream whilst ensuring the operation 
does not block.

It achieves this by basically following this pattern:

1. Call "select" on the stream and see if any data is available. If not, sleep 
and reiterate.

2. If there is data available, it reads a single byte from the stream and 
stores is to return at the end.

It supports most streams and sockets which have a real fd backing (and thus 
support "select").


There are a couple reasons you may need to do this, e.x. certain interactive 
scenarios, I won't go into it too much.


The python-nonblock library also bundles a layer which sits on top of that 
method, called BackgroundRead. This interface launches a thread into the 
background, which reads blocks of arbitrary (user-provided) size into a 
variable on an object. So you could have a processing app which reads blocks of 
data from a source, processes them in the foreground whilst they continue to 
load up in the background.


That's all well and good, but we are getting to the meat of the issue: for 
large sources of available data (like a file on disk), while this method of 
operation is effective, it is SLOW, due to the overhead of a select syscall and 
libpython for every single byte. This is especially true on a loaded system, as 
it makes us a prime candidate for the scheduler to preempt our task and context 
switch us off the cpu!


I've been looking into ways to improve this, and have actually seemed to have 
struck gold. So on a standard linux HDD filesystem, the I/O block size is 4096. 
So, thanks to readahead, on a non-fragmented file, a read call for 1 byte will 
actually load up to 4096 bytes. libpython has this extra data, and calls like 
read1 will return it if available, but it does not expose this number. Thus, 
libraries like mine can't take advantage of it, which means that for a 
filesystem I/O read on linux, 4095 out of 4096 iterations of the two-step loop 
above are wasted effort.

So I've written up an additional function to the C code for BufferedReader, 
"getbuffn", which returns the number bytes currently buffered in libpython, but 
not yet returned to the application, and modified python-nonblock ( in the 
4.0branch_getbuffn branch ) with simple additions to take advantage of this 
extra information, when available. So if we detect that there are 4095 bytes 
already read and pending, we know for certain we can grab all 4095 bytes at 
once without blocking, or even needing a call to select!

So the new pattern for buffered streams that have getbuffn available, we can:

1. Select to see if data is available, if not rest and reiterate

2. Read a single byte off the stream

3. Check getbuffn, and if it returns >0 read that many bytes off the stream 
(Guaranteed to not block)


The performance improvements are * MASSIVE * with this change in place.

   On a 5 meg file from a VM which is running on an SSD, I average the 
following:
 
 Loaded system, non-cached I/O:
 
One-Fell-Swoop file.read() - .3 seconds
 
getbuffn-patched python and this impl - 3.1 seconds
 
unpatched python and this impl - 41 to 55 = 44 seconds. ( avg min - avg 
max)
 
 Unloaded system, cached I/O:
 
One-Fell-Swoop file.read() - .0017 seconds
 
getbuffn-patched python and this impl - .034 seconds
 
unpatched python and this impl - 45 seconds. ( not as variable as 
loaded system )

That's a 13,235% (thirteen-thousand two-hundred and five percent) performance 
boost on just a 5MB file, which just grows exponentially as the size of the 
dataset increases. These gains are just simply not possible without this 
information available (the amount remaining in the buffer).


So I've attached the simple patch (only additions, no modifications to existing 
functions) against python 3.6.4. The version of python-nonblock which supports 
this enhanced approach when available (and more details at the top of the 
README) can be found here: 

https://github.com/kata198/python-nonblock/tree/4.0branch_getbuffn

I've looked at the python 2.7 code too, and it seems that with minimal effort 
this same functionality can be provided there as well!


So, I'm an experienced developer who is willing to put in the legwork. Is this 
something that is possible to get merged upstream? If so, what are the steps I 
would need to take in order to make it so?

Re: Copy-on-write friendly Python garbage collection

[INADA Naoki]

FYI: https://bugs.python.org/issue31558
INADA Naoki  


On Mon, Jan 1, 2018 at 12:39 AM,   wrote:
> An interesting write up on something that is incorporated into Python 3.7 
> https://engineering.instagram.com/copy-on-write-friendly-python-garbage-collection-ad6ed5233ddf
>
> --
> Kindest regards.
>
> Mark Lawrence.
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list