date:20180508

On Wed, May 9, 2018 at 3:36 PM, Ian Kelly  wrote:
>
> while True:
> if we_are_done():
> break
> # do some stuff
> ...
> if error_occurred():
> break
> notify_user()
>
>
> Fixed, using idiomatic Python and without needing to use assignment in
> an expression.

Why is it that "while True" is idiomatic Python for a non-infinite
loop? Is it merely because Python currently has no other way to spell
certain loops? Surely it would be more idiomatic to encode the loop's
termination condition in the header, if it were possible.

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

Re: seeking deeper (language theory) reason behind Python design choice

On Tue, 08 May 2018 22:48:52 -0500, Python wrote:

> On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote:
>> Currently, the real reason is that lambda expressions are limited to a
>> single expression as the body of the function, and binding operations
>> in Python are statements.
> 
> ...which begs the question, why shouldn't assignments be expressions, as
> they are in many other languages?  TBH this is one of the few things
> about Python that I dislike.

No, it raises the question :-) Begging the question means to assume the 
answer to the same question you are asking.

As Chris already pointed out, there is a PEP in progress at the moment 
aimed at allowing assignment expressions (PEP 572). It is very 
controversial, but Guido appears to be in favour of it (as I am, although 
not necessarily in its current form). There's about a bazillion emails on 
the Python-Ideas and Python-Dev mailing lists arguing about it.

(Oh, and it goes *all the way back to February*.)

In the very earliest versions of Python, like 0.1, there was only a 
single = operator that was used for both equals and assignment, but that 
was changed by the first official 1.0 release. I don't know if that 
change was driven by personal preference (Guido just liked it better), 
bad experiences with bugs, or what.

But by the time 1.4 came around, Guido had settled on a clean separation 
between statements and expressions as part of Python's design.

That separation has gradually weakened over the years, with the addition 
of the ternary if operator and comprehensions, but it is still an 
important part of Python's design. You might find something on Guido's 
blogs or his various essays:

http://neopythonic.blogspot.com.au/

https://www.artima.com/weblogs/index.jsp?blogger=guido

https://legacy.python.org/doc/essays/

but I don't have time to go trawling the blogs for this.

It might simply be that Guido (like many people) considered assignment to 
fundamentally be an imperative command, not an expression.

Another reason is something Nick Coghlan (re-)discovered during the 
discussions for PEP 572, namely that if you allow the full, unrestricted 
assignment targets as an expression, the code is ambiguous or at least 
hard to understand the intent. That's why PEP 572 has limited assignments 
to just plain names, and not arbitrary assignment targets. Possibly Guido 
recognised this way back in Python 0.x as well.

>> since = in a statement on its own is not dangerous. People *almost
>> never* intend to write == for the side-effects only:
> 
> Seriously?  I do this--not every day, but more than occasionally, not
> just in Python.
> 
> flag = (spam == arg)

Of course we all do that, but it is nothing like what I said. I even gave 
fully-commented sample code, which you appear to have missed:

# don't care whether they are actually equal or not
# just want to call the __eq__ method for its side-effects
spam == arg + 1

I bet you never, ever, ever call == for the side-effects, throwing away 
the result of the comparison without using it or looking at it in any 
way. In many languages, such a comparison cannot even have side-effects, 
so it would be useless dead code.

>> # don't care whether they are actually equal or not 
>> # just want to call the __eq__ method for its side-effects
>> spam == arg + 1
>> 
>> Since that never happens in real life, there's no risk of accidentally
>> writing "spam = arg + 1" when you wanted "spam == arg + 1".
> 
> I've always felt that this mentality was insulting to the programmer:
> "You're too stupid to get this right."  Sure, I've created that bug in
> other languages (or rather its inverse) but not since college.  You make
> it a few times, you go nuts debugging it, you learn what it is, you
> never do it again.

And fortunately we don't have to deal with a steady stream of new 
programmers learning the language and making newbie errors, right?

If all programmers were as awesome as you and never made typos, the world 
would be a better place. But we know from experience that even 
experienced C programmers can make this mistake by accident.

Or deliberately:

https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-
of-2003/

or if that URL wraps: https://tinyurl.com/jpvbtua

Of course we all make mistakes, but some features and syntax are bug 
magnets: they *encourage* errors rather than discourage them. Anyone can 
mistype "flga" when they meant "flag", but the use of real words 
discourages that error since the reader can see that "flga" looks weird. 
But == and = are so similar that not only is it an easy typo to make, but 
its a hard typo to spot without a close, careful reading.

-- 
Steve

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

Re: Problem/bug with class definition inside function definition

2018-05-08 Thread Gregory Ewing


Alexey Muranov wrote:

   x = 42

   class C:
   x = x  # Works


I'd say it kind of works by accident, and is not really an
intended feature.

if Python does not allow to refer "simultaneously" to 
variables from different scopes if they have the same name.


It seems perfectly reasonable to me to have to use different
names to refer to different things in the same context. :-)

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

Re: seeking deeper (language theory) reason behind Python design choice

2018-05-08 Thread Ian Kelly

On Tue, May 8, 2018 at 9:48 PM, Python  wrote:
> On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote:
>> since = in a statement on its own is not dangerous. People *almost never*
>> intend to write == for the side-effects only:
>
> Seriously?  I do this--not every day, but more than occasionally, not
> just in Python.
>
> flag = (spam == arg)
> vs.
> if spam == arg:
> flag = True
> else:
> flag = False
> if flag:
> do_something()
> else:
> do_something_else()

As Chris pointed out, this is not an example of using == for side-effects only.

>> # don't care whether they are actually equal or not
>> # just want to call the __eq__ method for its side-effects
>> spam == arg + 1
>>
>> Since that never happens in real life, there's no risk of accidentally
>> writing "spam = arg + 1" when you wanted "spam == arg + 1".
>
> I've always felt that this mentality was insulting to the programmer:
> "You're too stupid to get this right."  Sure, I've created that bug in
> other languages (or rather its inverse) but not since college.  You
> make it a few times, you go nuts debugging it, you learn what it is,
> you never do it again.
>
> And, this kind of thing is what code reviews are for--Python isn't so
> idiot-proof that you can get away without doing them for any
> non-trivial code--so (IMO) the language should not prevent you from
> doing useful things *simply* because you *might* make a mistake.

I do code reviews every day, and I doubt that I would actually notice
if one of them slipped in '=' where '==' was intended. Hopefully it
would be caught by unit testing though.

>  I'll
> give you an example that is both a case where Python's design choices
> make creating a bug easier, AND a case where allowing assignments to
> be expressions would save you.
>
> flag = we_are_done()
> while not flag:
> # do some stuff
> ...
> if error_occured():
> break
> falg = we_are_done()
> notify_user()
># flag will be checked again later, perhaps for error reporting


while True:
if we_are_done():
break
# do some stuff
...
if error_occurred():
break
notify_user()


Fixed, using idiomatic Python and without needing to use assignment in
an expression.

> Here, a common programming pattern (prime the loop control variable)
> gets you in trouble, because the assignment happens in two places, and
> you mistyped one of them.  There's no syntax error, but your program
> will execute forever, unless you were already done on the first call
> to prime the flag, or an error occurs.  This is probably worse than
> the = vs. == error, because your brain tends to "autocorrect" certain
> kinds of spelling errors, whereas experienced programmers learn to
> look for (or avoid entirely) the assignment vs. comparison bug.  The
> error here is reasonably easy to spot, given the trivial nature of the
> example, but would likely be harder to spot in more complex code with
> longer, more meaningful variable names.
>
> This example also is a case FOR allowing assignments to be
> expressions.  If Python allowed them, you could rewrite this as:
>
>while not (flag = we_are_done()):
> ...
> if error_occured():
> break
>notify_user()
># flag will be checked again later, perhaps for error reporting
>
> This COMPLETELY PREVENTS the spelling bug in the code above, since the
> assignment only happens in one place; and as a bonus it's less code.

Or just use an IDE with variable name autocompletion.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

2018-05-08 Thread Shlomo Anglister


Shlomo Anglister  added the comment:

This issue is in review stage for a long time.
What's holding it?

On Wed, May 9, 2018 at 8:24 AM, Shlomo Anglister 
wrote:

>
> Shlomo Anglister  added the comment:
>
> Thanks @serhiy.storchaka and @corona10 !
> I read it, documented the relation and failed to see the duplication.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)

2018-05-08 Thread Shlomo Anglister


Change by Shlomo Anglister :


--
nosy: +anglister

___
Python tracker 

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

[issue33296] datetime.datetime.utcfromtimestamp call decimal causes precision loss

2018-05-08 Thread Shlomo Anglister


Shlomo Anglister  added the comment:

Thanks @serhiy.storchaka and @corona10 !
I read it, documented the relation and failed to see the duplication.

--

___
Python tracker 

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

Re: seeking deeper (language theory) reason behind Python design choice

On Wed, May 9, 2018 at 1:48 PM, Python  wrote:
>> since = in a statement on its own is not dangerous. People *almost never*
>> intend to write == for the side-effects only:
>
> Seriously?  I do this--not every day, but more than occasionally, not
> just in Python.
>
> flag = (spam == arg)
> vs.
> if spam == arg:
> flag = True
> else:
> flag = False
> if flag:
> do_something()
> else:
> do_something_else()

That's not "side effects only". You're evaluating a comparison for its
result - its primary effect. You're assigning the result of the
comparison to something.

Using equality comparisons for side effects would look like this:

spam == arg

No assignment. Just that, as a statement all on its own. It's
perfectly legal, but I doubt you've ever actually done this.

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

[issue33445] test_cprofile should fail instead of displaying a message


miss-islington  added the comment:


New changeset c925108b991b9c5f0402feb0e7f725ee3ac7da11 by Miss Islington (bot) 
in branch '3.6':
closes bpo-33445: fail properly in test_cprofile() (GH-6727)
https://github.com/python/cpython/commit/c925108b991b9c5f0402feb0e7f725ee3ac7da11


--

___
Python tracker 

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

[issue33445] test_cprofile should fail instead of displaying a message


miss-islington  added the comment:


New changeset 263523ae217e1af580628b4fe0609194823a51aa by Miss Islington (bot) 
in branch '3.7':
closes bpo-33445: fail properly in test_cprofile() (GH-6727)
https://github.com/python/cpython/commit/263523ae217e1af580628b4fe0609194823a51aa


--
nosy: +miss-islington

___
Python tracker 

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

Re: seeking deeper (language theory) reason behind Python design choice

2018-05-08 Thread Python

On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote:
> Currently, the real reason is that lambda expressions are limited to a 
> single expression as the body of the function, and binding operations in 
> Python are statements. 

...which begs the question, why shouldn't assignments be expressions,
as they are in many other languages?  TBH this is one of the few
things about Python that I dislike.

> > So far, no satisfying answer has come up, except for maybe to avoid a
> > programmer accidentally typing `=` instead of `==`, which I find a bit
> > unsatisfying as the only reason.
> 
> No, that's the reason why = is a statement not an expression. That's not 
> why statements aren't allowed in lambdas. If we had blocks, this would be 
> perfectly acceptable:
> 
> lambda arg: %%%START BLOCK
> spam = arg + 1
> ...
> %%%END BLOCK
> 
> since = in a statement on its own is not dangerous. People *almost never* 
> intend to write == for the side-effects only:

Seriously?  I do this--not every day, but more than occasionally, not
just in Python.

flag = (spam == arg)
vs.
if spam == arg:
flag = True
else:
flag = False
if flag:
do_something()
else:
do_something_else()

Obviously this is a simple example which could be rewritten and/or the
comparison copy-pasted; assume a more complex system where you need to
check if the two objects were equal in multiple places, but obtaining
the objects is computationally expensive (say, processing a large file
to obtain a large list of objects), and comparing them is likewise
computationally expensive.

> # don't care whether they are actually equal or not
> # just want to call the __eq__ method for its side-effects
> spam == arg + 1
> 
> Since that never happens in real life, there's no risk of accidentally 
> writing "spam = arg + 1" when you wanted "spam == arg + 1".

I've always felt that this mentality was insulting to the programmer:
"You're too stupid to get this right."  Sure, I've created that bug in
other languages (or rather its inverse) but not since college.  You
make it a few times, you go nuts debugging it, you learn what it is,
you never do it again.

And, this kind of thing is what code reviews are for--Python isn't so
idiot-proof that you can get away without doing them for any
non-trivial code--so (IMO) the language should not prevent you from
doing useful things *simply* because you *might* make a mistake.  I'll
give you an example that is both a case where Python's design choices
make creating a bug easier, AND a case where allowing assignments to
be expressions would save you.

flag = we_are_done()
while not flag:
# do some stuff
...
if error_occured():
break
falg = we_are_done()
notify_user()
   # flag will be checked again later, perhaps for error reporting

Here, a common programming pattern (prime the loop control variable)
gets you in trouble, because the assignment happens in two places, and
you mistyped one of them.  There's no syntax error, but your program
will execute forever, unless you were already done on the first call
to prime the flag, or an error occurs.  This is probably worse than
the = vs. == error, because your brain tends to "autocorrect" certain
kinds of spelling errors, whereas experienced programmers learn to
look for (or avoid entirely) the assignment vs. comparison bug.  The
error here is reasonably easy to spot, given the trivial nature of the
example, but would likely be harder to spot in more complex code with
longer, more meaningful variable names.

This example also is a case FOR allowing assignments to be
expressions.  If Python allowed them, you could rewrite this as:

   while not (flag = we_are_done()):
...
if error_occured():
break
   notify_user()
   # flag will be checked again later, perhaps for error reporting

This COMPLETELY PREVENTS the spelling bug in the code above, since the
assignment only happens in one place; and as a bonus it's less code.

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

[issue33445] test_cprofile should fail instead of displaying a message


Change by miss-islington :


--
pull_requests: +6426

___
Python tracker 

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

[issue33445] test_cprofile should fail instead of displaying a message


Change by miss-islington :


--
pull_requests: +6425

___
Python tracker 

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

[issue33445] test_cprofile should fail instead of displaying a message

2018-05-08 Thread Benjamin Peterson


Benjamin Peterson  added the comment:


New changeset ac9240b9be31d073d1b2e50ce53481ff0fc9ed23 by Benjamin Peterson 
(jdemeyer) in branch 'master':
closes bpo-33445: fail properly in test_cprofile() (GH-6727)
https://github.com/python/cpython/commit/ac9240b9be31d073d1b2e50ce53481ff0fc9ed23


--
nosy: +benjamin.peterson
resolution:  -> fixed
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: Suggestion for a "data" object syntax

On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:

> I don't propose to remove spaces, 

And that is why the syntax will be ambiguous. So long as whitespace is 
*allowed* but not *required* around operators, there will be ambiguity 
between a - b and a - b with no way to tell whether they are intended as 
two items or one.

> but I propose Tab-separated elements.

We already have tab-separated elements in Python. It is allowed to use 
tabs between any whitespace separated tokens.

The only restriction is that in Python 3 you must use *consistent* spaces 
or tabs but not a mix of both for indents.

> If I allow commas as well, this will become not so simple, probably.
> Also I don't propose syntax for e-mail code exchange, but rather syntax
> for *work* an this can potentially help a lot of people in everyday
> work.

/head-desk

You: "I have invented amazing new syntax that cannot be exchanged by 
email. Here, let me email some examples to you."

Do you understand that you have already emailed samples of this proposed 
code?

> Also I don't know what kind of human thinks that this:
>  a + b
>  is two elements "a" and "+ b"
> What is "+ b"? 

It is unary plus followed by b.

If you don't know Python's existing syntax, how can you possibly expect 
to invent new syntax?

> And who writes "- b" with a space in unary minus? I don't. Nobody does.

Oh well, if you don't, then clearly nobody in the world, and no code 
generators, could possibly do it. Because Mikhail says so.

> Is it allowed? yes. no problem.

Since it is allowed, it is a HUGE problem for your syntax, since your 
syntax cannot distinguish between the two cases.

[...]
> There is "invisible" difference in indentations tabs vs spaces - so
> what? 

That means that people will look at a piece of code and not know whether 
they are seeing spaces or tabs, since they are both invisible.

> I don't want spaces or tabs visible - there is toggle "show tabs"
> and "toggle show space" for that

/head-desk

You: "This syntax doesn't need tabs and spaces to be visible. Just use 
the Show Tabs and Show Spaces commands on your editor to make them 
visible."

> Those are basically universal features. And thousands of Python people
> already use tabs to align columns so you have to accept it

Current syntax allows people to use tabs to align columns, and it remains 
unambiguous no matter how wacky people align their data, because of the 
commas. Even if they think they are writing Fortran with fixed column 
widths, it is still unambiguous to both the human reader and the parser:

data = [+   a   ,   -b  ,
-   foo ,   +bar,   ]

even if they separate operators from their operands with tabs. Paste that 
into your Python interpreter, and it has an unambiguous meaning.

The same does not apply to your syntax. Take out the commas, and it is 
impossible to tell what the code means or how many columns it has.

>> Using a particular editor is not and will not be a mandatory
>> requirement for Python.
> 
> Using outdated tools or being PEBCAK are not and will not be
> justification for language syntax improvements.

It is not your choice of what editors people are permitted to use in 
order to read and write Python.

[...]
>> - the first one allows you to write it as a single line:
>>
>> L = ((a, 1), (b, 2), (c, 3), (foobar, 4))
>>
>>   instead of wasting vertical space;
> 
> Wasting space you say? You economize paper for printing out?

No. I arrange code in the best way I see fit, depending on the code. 
Sometimes that means I put things on a single line, so as to fit more 
lines into a single screen, sometimes it means I spread things out over 
multiple lines in order to get maximum benefit from two dimensional 
layout. It all depends on the code I am writing and I use whatever is 
best for the situation.

>> - the first one is unambiguous while the second is ambiguous;
> 
> I think it's time to reveal what exactly you mean here.

For the fourth time, it means that the current syntax is unambiguous and 
only ever has a single meaning. Your suggestion is ambiguous, it cannot 
be parsed into a single meaning, and you have to guess what the code 
possibly means.

A single expression like either of these:

a   +   b

a   +b

under your syntax have TWO legal meanings, and there is no way to tell 
which is required except to guess.

I do not know how to make it more clear.

>> - the first one can include nested data structures, while
>>   the second cannot.
> 
> Why it can't? did you read the original e-mail?

Of course I did. You said:

"To present nesting of elements of higher than 2 levels, 
normal Python syntax can be used for deeper nesting"

and 

"So the idea is to cover only first two levels of 
nesting of course."

With bracket syntax, I can cover unlimited levels of nesting. Yours 
cannot.

-- 
Steve

--

[issue33447] Asynchronous lambda syntax

2018-05-08 Thread Noah Simon


Noah Simon  added the comment:

Actually, you wouldn't even need to import asyncio.

--

___
Python tracker 

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

[issue33447] Asynchronous lambda syntax

2018-05-08 Thread Noah Simon


New submission from Noah Simon :

It would be very useful to add an asynchronous lambda syntax, as a shortcut for 
coroutines. I'm not experienced enough to write a PEP or edit the C source, but 
I have some ideas for syntax:

import asyncio
foo = async lambda a,b: 5 + await bar(b)

--
components: asyncio
messages: 316304
nosy: Noah Simon, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Asynchronous lambda syntax
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

[issue28556] typing.py upgrades


miss-islington  added the comment:


New changeset 3c28a6387b48bad3fcae47906bc166d02a2f8ed2 by Miss Islington (bot) 
in branch '3.7':
bpo-28556: Minor fixes for typing module (GH-6732)
https://github.com/python/cpython/commit/3c28a6387b48bad3fcae47906bc166d02a2f8ed2


--
nosy: +miss-islington

___
Python tracker 

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

[issue33420] [typing] origin invariant broken


Ivan Levkivskyi  added the comment:

This is now fixed on master by 
https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40cdbc10a58c
 (the comment is updated).

--
resolution:  -> fixed
stage:  -> 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

[issue28556] typing.py upgrades


Change by miss-islington :


--
pull_requests: +6424

___
Python tracker 

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

[issue28556] typing.py upgrades


Ivan Levkivskyi  added the comment:


New changeset 43d12a6bd82bd09ac189069fe1eb40cdbc10a58c by Ivan Levkivskyi in 
branch 'master':
bpo-28556: Minor fixes for typing module (GH-6732)
https://github.com/python/cpython/commit/43d12a6bd82bd09ac189069fe1eb40cdbc10a58c


--

___
Python tracker 

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

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 3:14 AM, Ben Finney  wrote:
> Mikhail V  writes:
>
>> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
>> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
>> >> Just admit it, you try to troll me (or just pretend, I don't know).
>> >
>> > No, I am not trolling you.
>>
>> I don't believe you.
>
> If that's true – if you believe Chris is trolling you – then please do
> not continue the conversation. Since you have already decided Chris is
> trolling you,

Well, the thing is I don't know how exactly the word "trolling" can
be understood by different persons. I use it here in sense of "nitpicking".
Or "fooling around" I don't know actually.
So may be "trolling" has too negative associations to your ears?

As for Chris' attitude in this thread, and my point on this -
well, honestly yes, I believe he uses an opportunity to push
his own game. It has happened before - and now I know already,
so I know that trying to explain and honestly answer his questions ends up
in the same game of Chris - so I suppose he amuses himself
in such a way.
Same scenario happens here - he just completely neglects the whole
proposal straight away with a bold provoking statement.
But then asks "why do you think this a good proposal?"
Which I actually tried to describe in the very proposal.

So honestly I can't understand what game this time he prepared,
and not very much into this kind of things.

>
> This forum has no need of another thread attempting to “win” an argument
> that one side believes is dishonest.
>
> --
>  \   “The best in us does not require the worst in us: Our love of |
>   `\ other human beings does not need to be nurtured by delusion.” |
> _o__) —Sam Harris, at _Beyond Belief 2006_ |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue16733] Solaris ctypes_test failures

2018-05-08 Thread Greg Onufer

Greg Onufer added the comment:

The bitfields failures are due to Python not implementing bitfields the same as
the compiler.

https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html

"Signed and Unsigned int Bit-fields
Bit-fields which are declared as int (not signed int or unsigned int) can be
implemented by the compiler using either signed or unsigned types. This makes a
difference when extracting a value and deciding whether to sign extend it.

The Oracle Developer Studio compiler uses unsigned types for int bit-fields and
the gcc compiler uses signed types. Use the gcc –funsigned-bitfields flag to
control this behavior.

For more information, see the sixth list item at
https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Non_002dbugs.html.;

When the test compares the ctypes extraction of the bitfield (signed) and the
compiler-native extraction of the bitfield (unsigned), they miscompare if the
high-bit of the field is set.

If Python wants bitfields extracted from signed integral types to be signed,
the C code in the test case needs to account for the compiler implementation
defined behavior and sign extend the bitfield before returning it.

See patch in attachment. The bitfield tests pass with those changes.

--
keywords: +patch
nosy: +gco
Added file:
https://bugs.python.org/file47580/0001-Fix-ctypes-bitfield-test-code-to-account-for-compile.patch

___
Python tracker

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

Re: Suggestion for a "data" object syntax

2018-05-08 Thread Ben Finney

Mikhail V  writes:

> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
> >> Just admit it, you try to troll me (or just pretend, I don't know).
> >
> > No, I am not trolling you.
>
> I don't believe you.

If that's true – if you believe Chris is trolling you – then please do
not continue the conversation. Since you have already decided Chris is
trolling you, it follows that you will not respond productively to
anything he says to you. So this thread is already lost.

This forum has no need of another thread attempting to “win” an argument
that one side believes is dishonest.

-- 
 \   “The best in us does not require the worst in us: Our love of |
  `\ other human beings does not need to be nurtured by delusion.” |
_o__) —Sam Harris, at _Beyond Belief 2006_ |
Ben Finney

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

[issue27675] IDLE file completion has 2 bugs depending on open quote used

2018-05-08 Thread Cheryl Sabella


Cheryl Sabella  added the comment:

I can't seem to recreate this. I tried on Ubuntu with master and Windows with 
3.6.3.  I'm not sure if it's been fixed by another change or if I'm not doing 
the steps correctly to recreate it.

--
nosy: +csabella

___
Python tracker 

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

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
> On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
>> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
>>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
 Right? Your issues with tabs aside, I think it is impossible to ignore the
 the readability improvement. Not even speaking of how
 many commas and bracket you need to type in the first case.
>>>
>>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>>
>> Just admit it, you try to troll me (or just pretend, I don't know).
>
> No, I am not trolling you.

I don't believe you.


> Neither of those examples is program code. You are asking for a
> syntactic change to a *programming language*. Everything you've said
> is fine for a non-code format. Nothing is applicable to a programming
> language.

Everything I said in previous mail was related to your claim that it's
Ok (or even better?) readable
with brackets and commas in a table than without them.
I was not even starting this terminology course.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33414] Make shutil.copytree use os.scandir to take advantage of cached is_(dir|file|symlink)

2018-05-08 Thread Andrés Delfino


Andrés Delfino  added the comment:

I believe you are right about being conservative with changing working code, 
specially when there's no proof about performance being improved.

I think its best to close this ticket. I'd do it myself, but I know what 
resolution applies here.

--

___
Python tracker 

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

Re: Suggestion for a "data" object syntax

2018-05-08 Thread Mark Lawrence


On 08/05/18 22:33, Chris Angelico wrote:

On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:

On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:

Right? Your issues with tabs aside, I think it is impossible to ignore the
the readability improvement. Not even speaking of how
many commas and bracket you need to type in the first case.


That's incredibly subjective. Or else straight-up wrong, I'm not sure which.


Just admit it, you try to troll me (or just pretend, I don't know).


No, I am not trolling you.


Have you ever seen tables with commas left in there?


It's called CSV.


I've never seen in my whole life. And you should understand why.

Have you ever seen a website with sparse menu items or 'cloud' tags
with commas attached?
Have you ever heard someone claim that writing a 2d matrix down in a
single line is better that present it as a table?

So what you find _incredibly_ subjective here?


Neither of those examples is program code. You are asking for a
syntactic change to a *programming language*. Everything you've said
is fine for a non-code format. Nothing is applicable to a programming
language.


Why should this be a language feature? Why not just create a data file
and then load it, or use a triple quoted string and write your own
parser? What's the advantage of making this language syntax?


I am not sure what happens if I make another argument -
if it feels so easy for you to deny the obvious improvements (which
also supported by whole worlds' typography experience) then you can
just as easy deny pretty everything. How would we build any conversation
then?


Good question. You're clearly not interested in doing things the
existing (and easy) way, so there's no point debating this.
Fortunately for the rest of us, status quo wins a stalemate.

ChrisA



Please stop feeding the OP, to my knowledge he's never once come up with 
any sensible suggestion for Python.


--
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: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
>>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>>> the readability improvement. Not even speaking of how
>>> many commas and bracket you need to type in the first case.
>>
>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>
> Just admit it, you try to troll me (or just pretend, I don't know).

No, I am not trolling you.

> Have you ever seen tables with commas left in there?

It's called CSV.

> I've never seen in my whole life. And you should understand why.
>
> Have you ever seen a website with sparse menu items or 'cloud' tags
> with commas attached?
> Have you ever heard someone claim that writing a 2d matrix down in a
> single line is better that present it as a table?
>
> So what you find _incredibly_ subjective here?

Neither of those examples is program code. You are asking for a
syntactic change to a *programming language*. Everything you've said
is fine for a non-code format. Nothing is applicable to a programming
language.

>> Why should this be a language feature? Why not just create a data file
>> and then load it, or use a triple quoted string and write your own
>> parser? What's the advantage of making this language syntax?
>
> I am not sure what happens if I make another argument -
> if it feels so easy for you to deny the obvious improvements (which
> also supported by whole worlds' typography experience) then you can
> just as easy deny pretty everything. How would we build any conversation
> then?

Good question. You're clearly not interested in doing things the
existing (and easy) way, so there's no point debating this.
Fortunately for the rest of us, status quo wins a stalemate.

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

Re: Suggestion for a "data" object syntax

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>> the readability improvement. Not even speaking of how
>> many commas and bracket you need to type in the first case.
>
> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Just admit it, you try to troll me (or just pretend, I don't know).

Have you ever seen tables with commas left in there?
I've never seen in my whole life. And you should understand why.

Have you ever seen a website with sparse menu items or 'cloud' tags
with commas attached?
Have you ever heard someone claim that writing a 2d matrix down in a
single line is better that present it as a table?

So what you find _incredibly_ subjective here?

I am not telling tabulations work as they should in many code editors, but
there is a lot of work people invest to make better support for them in editors.
Here is another indirect benefit of adding such syntax, as editor developers
will be more motivated to improve the tabulation features.

> Why should this be a language feature? Why not just create a data file
> and then load it, or use a triple quoted string and write your own
> parser? What's the advantage of making this language syntax?

I am not sure what happens if I make another argument -
if it feels so easy for you to deny the obvious improvements (which
also supported by whole worlds' typography experience) then you can
just as easy deny pretty everything. How would we build any conversation
then?

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

[issue28556] typing.py upgrades


Change by Ivan Levkivskyi :


--
pull_requests: +6423

___
Python tracker 

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

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 6:16 AM, Mikhail V  wrote:
> Also I don't know what kind of human thinks that this:
>  a + b
>  is two elements "a" and "+ b"
> What is "+ b"?

Unary plus applied to whatever value 'b' is.

> And who writes "- b" with a space in unary minus?
> I don't. Nobody does. Is it allowed? yes. no problem.

You're making a syntax proposal. That means it has to cope with all
the vagaries of syntax, including things that you think "nobody does".

>> - the first one is unambiguous while the second is ambiguous;
>
> I think it's time to reveal what exactly you mean here.
> In the above example there is nothing ambigious.
> At least not for someone who is Ok with basic editing
> skills.

There are things that are ambiguous to the Python syntax parser.

If you want to create a completely new syntax that happens to
incorporate some Python expressions, that's not a problem. It isn't a
Python syntax enhancement, it is a completely separate file format,
and you can do what you like with that. You can use tabs to separate
tokens, eval() those tokens to figure out the actual value, and then
build the resulting data structure according to your rules. And it's
100% acceptable to demand a stricter form of Python syntax within your
tokens (eg "no tabs allowed"), because it's your own data file.

And, even better: You can write code to parse this, without needing
approval from the core devs. The code you write doesn't have to wait
until Python 3.8 is released (two years from now); it can run on
existing interpreters. All the advantages are on your side.

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

[issue13044] pdb throws AttributeError at end of debugging session


Change by Xavier de Gaye :


Added file: https://bugs.python.org/file47578/lazy_import.diff

___
Python tracker 

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

[issue13044] pdb throws AttributeError at end of debugging session


Change by Xavier de Gaye :


Added file: https://bugs.python.org/file47579/gdb_backtrace.txt

___
Python tracker 

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

[issue13044] pdb throws AttributeError at end of debugging session


Xavier de Gaye  added the comment:

Nosying Serhiy as this post attempts to answer one of the questions raised in 
msg315588 in issue 33328:
> Is it good that the debugger is enabled at the shutdown stage?

This post has four different sections showing that the successive and 
incremental attempts at fixing the current code to have a destructor traced in 
the shutdown stage may lead to a segfault.

Section 1 - Current status:
---
A run with Python 3.6.5 of the following code proposed in the previous 
msg176993 gives now a different output and the C destructor is still not 
traced, but now it is not even called:

1 class C:
2 def __del__(self):
3 print('deleted')
4
5 c = C()
6 import pdb; pdb.set_trace()
7 x = 1

$ python test_destructor.py
> test_destructor.py(7)()
-> x = 1
(Pdb) step
--Return--
> test_destructor.py(7)()->None
-> x = 1
(Pdb) step
--Call--
Exception ignored in: 
Traceback (most recent call last):
  File "/usr/lib/python3.6/types.py", line 27, in _ag
  File "/usr/lib/python3.6/bdb.py", line 53, in trace_dispatch
  File "/usr/lib/python3.6/bdb.py", line 85, in dispatch_call
  File "/usr/lib/python3.6/pdb.py", line 251, in user_call
  File "/usr/lib/python3.6/pdb.py", line 351, in interaction
  File "/usr/lib/python3.6/pdb.py", line 1453, in print_stack_entry
  File "/usr/lib/python3.6/bdb.py", line 394, in format_stack_entry
TypeError: 'NoneType' object is not callable

Section 2 - Fix using PR 6730:
--
PR 6730 in issue 33446 fixes a bug in the pdb module that leaks a reference to 
frame->f_locals through its curframe_locals attribute.
There is no major change when the current Python master branch is run with PR 
6730, the destructor is still not traced and not called.

Section 3 - Fix a bdb leak:
---
After returning from the '__main__' module, the Bdb.bdb instance keeps a 
reference to the module through its botframe attribute and prevents the 
corresponding frame from being deallocated at the end of 
_PyEval_EvalCodeWithName() (the frame reference count is 2 instead of 1).  The 
attached bdb_leak.diff patch fixes this, and when PR 6730 and bdb_leak.diff are 
run, the destructor is now traced but this fails with an exception in bdb:

$ /home/xavier/src/python/master/python test_destructor.py
> ./test_destructor.py(7)()
-> x = 1
(Pdb) step
--Return--
> ./test_destructor.py(7)()->None
-> x = 1
(Pdb) step
Exception ignored in: 
Traceback (most recent call last):
  File "test_destructor.py", line 3, in __del__
  File "test_destructor.py", line 3, in __del__
  File "/home/xavier/src/python/master/Lib/bdb.py", line 88, in trace_dispatch
  File "/home/xavier/src/python/master/Lib/bdb.py", line 115, in dispatch_line
  File "/home/xavier/src/python/master/Lib/pdb.py", line 262, in user_line
  File "/home/xavier/src/python/master/Lib/pdb.py", line 352, in interaction
  File "/home/xavier/src/python/master/Lib/pdb.py", line 1454, in 
print_stack_entry
  File "/home/xavier/src/python/master/Lib/bdb.py", line 544, in 
format_stack_entry
ImportError: sys.meta_path is None, Python is likely shutting down

Section 4 - Remove the lazy import:
---
The attached lazy_import.diff patch includes the changes in bdb_leak.diff patch 
and replaces the lazy imports causing the previous ImportError with imports at 
the start of the bdb module.  Running test_destructor.py fails now with a 
segfault:

$ /home/xavier/src/python/master/python test_destructor.py
> ./test_destructor.py(7)()
-> x = 1
(Pdb) step
--Return--
> ./test_destructor.py(7)()->None
-> x = 1
(Pdb) step
> ./test_destructor.py(3)__del__()
-> print('deleted')
Segmentation fault (core dumped)

The gdb back trace is attached at gdb_backtrace.txt.

Conclusion:
---
It seems that tracing should be prevented in the shutdown stage and that 
multiple little bugs have hidden that fact (when tracing is done with pdb).
Not sure if tracing with PyEval_SetTrace() could be allowed in that stage.
BTW coverage.py uses PyEval_SetTrace() and I have noticed that coverage.py does 
not trace either the destructor in test_destructor.py (nosying Ned).

--
keywords: +patch
nosy: +nedbat, serhiy.storchaka
Added file: https://bugs.python.org/file47577/bdb_leak.diff

___
Python tracker 

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

Re: Suggestion for a "data" object syntax

On Tue, May 8, 2018 at 6:20 PM, Steven D'Aprano
 wrote:
> On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote:
>
>>> Last time you brought up this idea, you were told that it is ambiguous.
>>> Using whitespace alone, it is impossible to distinguish between
>>>
>>> a + b
>>>
>>> and
>>>
>>> a + b
>>>
>>>
>>> Can you see the difference? Of course not. That's the whole point. It
>>> is ambiguous. The first is a single item consisting of a plus b, and
>>> the second is two items consisting of a, following by unary plus b.
>>
>> Can you be more precise what issue are you addressing?
>
> Was I not clear enough the first time?
>
> When you write "a + b" it is impossible for either the human reader or
> the interpreter to tell whether that is meant to be two items separated
> by white space ("a" and "+b") or a single item ("a+b").
>
> There is no acceptable work-around or fix for this.
>
> * It is not acceptable to prohibit whitespace between unary operators
>   and their operand;
>
> * or to require spaces rather than tabs between binary operators
>   and their operands;
>

Sorry this all does not seem to even refer to my proposal.

I don't propose to remove spaces, but I propose Tab-separated
elements. If I allow commas as well, this will become not so simple,
probably. Also I don't propose syntax for e-mail code exchange,
but rather syntax for *work* an this can potentially help a lot of people
in everyday work.

Also I don't know what kind of human thinks that this:
 a + b
 is two elements "a" and "+ b"
What is "+ b"? And who writes "- b" with a space in unary minus?
I don't. Nobody does. Is it allowed? yes. no problem.

(It would be great if you group the issues
related to usability separetely from technical problems
with parser. That will help to understand you comments.)

>> Last time and
>> this time I told it uses TAB character to separate elements.
>
> That's not my recollection. As I remember it, it was *your* idea to use
> tab characters, and everyone told you that was not an acceptable work-
> around.

Yes my idea, but not sure what is you concern right now.
IIRC back then, you were the *only one* who commented something about
Tab and parsing, and made some mysterious example with eval("\t") which
I still don't know what it should explain exactly.
You say "everyone?" ... Hmm, now I am starting to suspect - maybe
each your post really represents a result of a quick meeting
regarding each raised proposal?
That would explain the usage of plural "us".

>>> There's also the problem that your syntax requires the *invisible*
>>> difference between tabs and spaces to be treated as syntactically
>>> meaningful.

There is "invisible" difference in indentations tabs vs spaces - so what?
I don't want spaces or tabs visible - there is toggle "show tabs" and "toggle
show space" for that and many more usability features, as I already said.
Look, I work with layouts - there are: Indents, Tabs, spaces, En
space, Em space,
thin space, non-breaking space, "indent to here" control characters.
All those are useful parts of inner syntax - all are "invisible".
What point are you making after all?

Those are basically universal features. And thousands of Python people
already use tabs to align columns so you have to accept it - it is
part of many source code and tabulation formatting is a good and
useful feature, although not all editors cope good with that.

>>
>> What editor do you use? My editor can toggle tabs highlighting as
>> arrows, and I suppose almost any editor has good support for
>> highlighting of characters by search, etc. For NPP there are even
>> plugins like Regex helper.
>
> Using a particular editor is not and will not be a mandatory requirement
> for Python.

Using outdated tools or being PEBCAK are not and will not be justification for
language syntax improvements. Using an editor from 85 - everyone else
should bother?
As said there is already tons of code with which you may be unsatisfied
when you paste it into REPL, but nearly nobody uses REPL for work.

>
> [...]
>> So you would prefer this:
>>
>> L = (
>> (a, 1),
>> (b, 2),
>> (c, 3),
>> (foobar, 4))
>>
>> over this:
>>
>> L === T/T:
>> a1
>> b2
>> c3
>> foobar4
>>
>> Right?
>
> I am amused that you have obviously gone to a lot of trouble to carefully
> line up the columns, and yet they aren't even aligned -- "foobar" extends
> into the second column, pushing the "4" out to the right.

No, i haven't. It takes much less time to type that than bracketed
version. Though I am amused that you've noticed the misaligned
element but can't notice how bad the bracketed version look.
Ok, Steve, as said, I hear you - you like the ugly one, I'll pick the cute
one ;-)

> There is no doubt that the first is HUGELY better:
>
> - it uses the standard = assignment operator, not a
>   special "===" operator;
>
> - there's no cryptic and mysterious "T/T" code which looks

[issue32717] Document PEP 560


Change by Ivan Levkivskyi :


--
resolution:  -> fixed
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

[issue27465] IDLE:Make help source menu entries unique and sorted.

2018-05-08 Thread Cheryl Sabella


Cheryl Sabella  added the comment:

> Currently, names are displayed in the order added.  I believe sorting would 
> be better, especially when one adds more than 2 entries.  That should also be 
> easy.

I'm wondering if it would be worthwhile to add Drag and Drop functionality to 
the Help listbox to allow users to move the items into any order they want?

--
nosy: +csabella

___
Python tracker 

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

[issue30167] site.main() does not work on Python 3.6 and superior if PYTHONSTARTUP is set

2018-05-08 Thread steverweber


steverweber  added the comment:

ref to other projects that hit this issue.

https://gitlab.idiap.ch/bob/bob.buildout/issues/15
https://github.com/saltstack/salt/issues/45080
https://groups.google.com/forum/#!msg/comp.lang.python/tpfiHAJhl9Y/hZj1f50vBQAJ

--
nosy: +steverweber

___
Python tracker 

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

[issue33446] destructors of local variables are not traced


Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue16653] reference kept in f_locals prevents the tracing/profiling of a destructor


Xavier de Gaye  added the comment:

Closing as a duplicate of issue 33446 which has a wider scope and a PR.

--
resolution:  -> duplicate
stage:  -> 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

[issue32717] Document PEP 560


miss-islington  added the comment:


New changeset 101d0d585f99a3b8c8d070b9d4dea15fa3daff62 by Miss Islington (bot) 
in branch '3.7':
bpo-32717: Document PEP 560 (GH-6726)
https://github.com/python/cpython/commit/101d0d585f99a3b8c8d070b9d4dea15fa3daff62


--
nosy: +miss-islington

___
Python tracker 

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

[issue33446] destructors of local variables are not traced


Xavier de Gaye  added the comment:

In both cases the destructor cannot be traced because it is invoked from 
functions called from [1] call_trace() where tracing is disabled:

  Case local variable 'a':
On line 12, just before executing this line with a pdb step command, the 
object referenced by 'a' lives in frame->f_locals. The step command causes the 
ceval loop to execute the bytecodes corresponding to the statement on line 12 
and to eventualy call [2] call_trampoline() with a 'return' trace event and to 
call PyFrame_FastToLocalsWithError() here. This last call causes the last 
reference to the previous 'a' object in frame->f_locals to be decremented and 
the object to be deallocated but without its destructor being traced as tracing 
has been disabled in call_trace().

  Case local variable 'b':
Upon exiting the frame of the 'main' function, pdb keeps a reference to 
frame->f_locals through its own attribute curframe_locals.  Next, after 
returning to the 'main' caller, this reference is decremented since 
pdb.curframe_locals references now another object and the dictionary referenced 
by the previous frame f_locals (the frame of 'main') is deallocated, but this 
happens within pdb where tracing is disabled and the destructor of the object 
that had been referenced by 'b' is therefore not traced.

PR 6730 proposes a fix for both cases.

[1] https://github.com/python/cpython/blob/master/Python/ceval.c#L4247
[2] https://github.com/python/cpython/blob/master/Python/sysmodule.c#L462

--

___
Python tracker 

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

[issue33446] destructors of local variables are not traced


Change by Xavier de Gaye :


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

___
Python tracker 

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

[issue32717] Document PEP 560


Change by miss-islington :


--
pull_requests: +6421

___
Python tracker 

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

[issue32717] Document PEP 560


Ivan Levkivskyi  added the comment:


New changeset bd5f96581bf23f6d05fc106996428a8043b6b084 by Ivan Levkivskyi in 
branch 'master':
bpo-32717: Document PEP 560 (GH-6726)
https://github.com/python/cpython/commit/bd5f96581bf23f6d05fc106996428a8043b6b084


--

___
Python tracker 

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

[issue33446] destructors of local variables are not traced


New submission from Xavier de Gaye :

In the following code, the destructors of objects referenced by the 'a' and 'b' 
local variables are not traced by the 'step' command of pdb.

 1 class C:
 2 def __init__(self, name):
 3 self.name = name
 4
 5 def __del__(self):
 6 print('"%s" destructor' % self.name)
 7
 8 def main():
 9 a = C('a')
10 b = C('b')
11 import pdb; pdb.set_trace()
12 a = 1
13
14 main()

--
components: Interpreter Core, Library (Lib)
messages: 316290
nosy: xdegaye
priority: normal
severity: normal
status: open
title: destructors of local variables are not traced
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33444] Memory leak/high usage on copy in different thread

2018-05-08 Thread Antoine Pitrou


Change by Antoine Pitrou :


--
resolution:  -> not a bug
stage:  -> 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

[issue33444] Memory leak/high usage on copy in different thread

2018-05-08 Thread Antoine Pitrou


Antoine Pitrou  added the comment:

Yes, this looks surprising, but there is no memory leak here, just memory 
fragmentation in the glibc allocator.  This is the program I used to diagnose 
it:
https://gist.github.com/pitrou/6c5310d4c721436165666044e3c31158

At the end the program prints glibc allocator stats as returned by mallinfo() 
(see http://man7.org/linux/man-pages/man3/mallinfo.3.html). On my system, the 
process takes 480 MB RSS and "fordblks" (the total number of bytes in free 
blocks) is 478 MB. However, "keepcost" (the releasable free space) is only 30 
MB.  The rest is probably interspersed with internal interpreter structures 
that have stayed alive.

The fragmentation seems to depend on the number of threads.  If you start the 
executor with only one thread, memory consumption is much lower.  This makes 
sense: by ensuring all operations happen in order with little concurrency, we 
minimize the chance that short-lived data gets interspersed with longer-lived 
data.

--

___
Python tracker 

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

Re: Module, Package

2018-05-08 Thread Sharan Basappa

On Tuesday, 8 May 2018 13:05:58 UTC+5:30, Steven D'Aprano  wrote:
> On Mon, 07 May 2018 09:53:45 -0700, Sharan Basappa wrote:
> 
> > I am a bit confused between module and package in Python. Does a module
> > contain package or vice versa? When we import something in Python, do we
> > import a module or a package?
> 
> The term "module" in Python has multiple meanings:
> 
> - a particular kind of object, types.ModuleType
> 
> - a single importable .py, .pyc etc file
> 
> A package is a logical collection of importable .py etc files, usually 
> collected inside a single directory. When you import a module of a 
> package, that gives you a module object.
> 
> Normally we would say that packages contain modules. For example, if you 
> have this file structure:
> 
> 
> library/
> +-- __init__.py   # special file which defines a package
> +-- widgets.py
> +-- stuff/
> +-- __init__.py
> +-- things.py
> 
> 
> then we have a package "library", which in turn contains a submodule 
> "library.widgets", and a subpackage "library.stuff", which in turn 
> contains a submodule "library.stuff.things".
> 
> Each of these lines imports a module object:
> 
> import library
> import library.stuff
> import library.stuff.things
> import library.widgets
> 
> from library import widgets
> from library.stuff import things
> 
> 
> Effectively, "packages" relates to how you arrange the files on disk; 
> "modules" relates to what happens when you import them.
> 
> 
> -- 
> Steve

Wow! Thanks a lot.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: problem in compiling C API in mingw

2018-05-08 Thread m.overmeyer--- via Python-list

On Tuesday, 26 July 2011 23:53:36 UTC, llw...@gmail.com  wrote:
> Hi all again, 
>   I wonder if so far only Python 2.5.x support c extension. I try the
> MSVC 2010 and 2008, also try mingw (gcc 4.x.x) and swig. But even I try
> the simplest example, it said 
> 
> example_wrap.o:example_wrap.c:(.text+0x10ac): undefined reference to 
> `_imp__PyObject_Free'
> example_wrap.o:example_wrap.c:(.text+0x10f5): undefined reference to 
> `_imp__PyCapsule_Import'
> example_wrap.o:example_wrap.c:(.text+0x1100): undefined reference to 
> `_imp__PyErr_Occurred'
> example_wrap.o:example_wrap.c:(.text+0x110e): undefined reference to 
> `_imp__PyErr_Clear'
> example_wrap.o:example_wrap.c:(.text+0x1125): undefined reference to 
> `_imp__PyImport_AddModule'
> example_wrap.o:example_wrap.c:(.text+0x1144): undefined reference to 
> `_imp__PyCapsule_New'
> example_wrap.o:example_wrap.c:(.text+0x1165): undefined reference to 
> `_imp__PyModule_AddObject'
> example_wrap.o:example_wrap.c:(.text+0x1170): undefined reference to 
> `_imp__PyBaseObject_Type'
> example_wrap.o:example_wrap.c:(.text+0x11b2): undefined reference to 
> `_imp__PyObject_SetAttr'
> example_wrap.o:example_wrap.c:(.rdata+0x1e8): undefined reference to 
> `PyObject_GenericGetAttr'
> collect2: ld returned 1 exit status
> 
> and some sort like that.
> 
> So I try to use the compiler itself and get rid of all 3rd part tool,
> here is what I did
> 
> / source code
> #include "Python.h"
> 
> static  PyObject *
> ex_foo(PyObject *self, PyObject *args)
> {
> printf("Hello, world n " );
> Py_INCREF(Py_None);
> return  Py_None;
> }
> 
> static  PyMethodDef example_methods[] = {
> {"foo" , ex_foo, METH_VARARGS, "foo() doc string" },
> {NULL , NULL }
> };
> 
> static  struct  PyModuleDef examplemodule = {
> PyModuleDef_HEAD_INIT,
> "example" ,
> "example module doc string" ,
> -1 ,
> example_methods,
> NULL ,
> NULL ,
> NULL ,
> NULL
> };
> 
> PyMODINIT_FUNC
> PyInit_example(void )
> {
> return  PyModule_Create();
> }
> 
> /// my setup.py
> from distutils.core import setup, Extension
> 
> module1 = Extension('example', sources = ['example.c'])
> 
> setup (name = 'example', version = '1.0', description = 'This is a demo 
> package', ext_modules = [module1])
> 
> 
> // running
> python setup.py build --compiler=mingw32
> 
> 
> $ python setup.py build --compiler=mingw32
> running build
> running build_ext
> building 'example' extension
> D:\Programs\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall "-Ic:\Program Files 
> (x8
> 6)\Python\include" "-Ic:\Program Files (x86)\Python\PC" -c example.c -o 
> build\te
> mp.win-amd64-3.1\Release\example.o
> writing build\temp.win-amd64-3.1\Release\example.def
> D:\Programs\MinGW\bin\gcc.exe -mno-cygwin -shared -s 
> build\temp.win-amd64-3.1\Re
> lease\example.o build\temp.win-amd64-3.1\Release\example.def "-Lc:\Program 
> Files
>  (x86)\Python\libs" "-Lc:\Program Files (x86)\Python\PCbuild\amd64" 
> -lpython31 -
> lmsvcr90 -o build\lib.win-amd64-3.1\example.pyd
> build\temp.win-amd64-3.1\Release\example.o:example.c:(.text+0x13): undefined 
> ref
> erence to `_imp___Py_NoneStruct'
> build\temp.win-amd64-3.1\Release\example.o:example.c:(.text+0x32): undefined 
> ref
> erence to `_imp__PyModule_Create2'
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
> - Original Message Ends 

You are linking against the static version of the Python library. If you link 
against the DLL version, this problem goes away.

-Lc:\Program Files(x86)\Python\libs" should just be "-Lc:\Program 
Files(x86)\Python\", assuming that's where the Python DLLs are.

See:
https://stackoverflow.com/questions/5159353/how-can-i-get-rid-of-the-imp-prefix-in-the-linker-in-vc#5159395

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

Re: Suggestion for a "data" object syntax

On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote:

>> Last time you brought up this idea, you were told that it is ambiguous.
>> Using whitespace alone, it is impossible to distinguish between
>>
>> a + b
>>
>> and
>>
>> a + b
>>
>>
>> Can you see the difference? Of course not. That's the whole point. It
>> is ambiguous. The first is a single item consisting of a plus b, and
>> the second is two items consisting of a, following by unary plus b.
> 
> Can you be more precise what issue are you addressing?

Was I not clear enough the first time?

When you write "a + b" it is impossible for either the human reader or 
the interpreter to tell whether that is meant to be two items separated 
by white space ("a" and "+b") or a single item ("a+b").

The same applies to "a - b".

There is no acceptable work-around or fix for this.

* It is not acceptable to prohibit whitespace between unary operators
  and their operand;

* or to require spaces rather than tabs between binary operators
  and their operands;

* or to make a subtle semantic difference between tabs and spaces
  of this sort.

Unix "make" files require tabs rather than spaces, and it is a constant 
source of bugs and frustration.

> Last time and
> this time I told it uses TAB character to separate elements.

That's not my recollection. As I remember it, it was *your* idea to use 
tab characters, and everyone told you that was not an acceptable work-
around.

Who told you to use tab characters? It would not have been any of the 
core developers. Many of them would rather ban tabs than require them.

>> There's also the problem that your syntax requires the *invisible*
>> difference between tabs and spaces to be treated as syntactically
>> meaningful.
> 
> What editor do you use? My editor can toggle tabs highlighting as
> arrows, and I suppose almost any editor has good support for
> highlighting of characters by search, etc. For NPP there are even
> plugins like Regex helper.

Using a particular editor is not and will not be a mandatory requirement 
for Python.

[...]
> So you would prefer this:
> 
> L = (
> (a, 1),
> (b, 2),
> (c, 3),
> (foobar, 4))
> 
> over this:
> 
> L === T/T:
> a1
> b2
> c3
> foobar4
> 
> Right?

I am amused that you have obviously gone to a lot of trouble to carefully 
line up the columns, and yet they aren't even aligned -- "foobar" extends 
into the second column, pushing the "4" out to the right.

There is no doubt that the first is HUGELY better:

- it uses the standard = assignment operator, not a 
  special "===" operator;

- there's no cryptic and mysterious "T/T" code which looks like
  you are dividing T by T;

- the first one allows you to write it as a single line:

L = ((a, 1), (b, 2), (c, 3), (foobar, 4))

  instead of wasting vertical space;

- the first one is unambiguous while the second is ambiguous;

- the first one can include nested data structures, while 
  the second cannot.

There is only one advantage to the second format. It gives bad 
programmers a justification to waste time while pretending to be working, 
as they carefully align their columns, then realign them each time the 
data changes.

> Your issues with tabs aside, I think it is impossible to ignore
> the the readability improvement.

An interesting philosophical conundrum... is it possible to ignore 
something which isn't there?

If there is no elephant in the room, and nobody mentions it, are they 
ignoring it?

-- 
Steve

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

Re: Suggestion for a "data" object syntax

2018-05-08 Thread Liste guru


Il 08/05/2018 14:52, Mikhail V ha scritto:

 ...

What editor do you use? My editor can toggle tabs highlighting as arrows,
and I suppose almost any editor has good support for highlighting of
characters by search, etc. For NPP there are even plugins like Regex helper.


    I like to 'type program.py' and understand what's happening, 
without have to fire up an editor.


   While, in C++, the Microsoft IDE (and some other) mark the class 
members & the parameters so you can easily see what 'counter' is, a lot 
of guide says that you should call it 'm_counter' if it's a member or 
'counter_' if it's a parameter, just in case you don't have your editor 
(or you're colorblind or you don't like to have the parameters printed 
with a light grey ...).



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

[issue33437] Defining init in enums

2018-05-08 Thread Ethan Furman


Ethan Furman  added the comment:

That new example looks great!  Note that you don't need the parenthesis, though.

FYI: The same thing using the aenum library* would look like:

from aenum import Enum

class Coord(bytes, Enum):
_init_ = 'value label unit'

PX = [0], 'P.X', 'km'
PY = [1], 'P.Y', 'km'
VX = [2], 'V.X', 'km/s'
VY = [3], 'V.Y', 'km/s'


* aenum is the Advanced Enum library I wrote that has a few extra abilities.

--

___
Python tracker 

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

[issue33445] test_cprofile should fail instead of displaying a message

2018-05-08 Thread Jeroen Demeyer


Change by Jeroen Demeyer :


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

___
Python tracker 

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

[issue33445] test_cprofile should fail instead of displaying a message

2018-05-08 Thread Jeroen Demeyer


New submission from Jeroen Demeyer :

When this test from Lib/test/test_profile.py fail, it just prints a message and 
doesn't fail the testsuite:

def test_cprofile(self):
results = self.do_profiling()
expected = self.get_expected_output()
self.assertEqual(results[0], 1000)
for i, method in enumerate(self.methodnames):
if results[i+1] != expected[method]:
print("Stats.%s output for %s doesn't fit expectation!" %
  (method, self.profilerclass.__name__))
print('\n'.join(unified_diff(
  results[i+1].split('\n'),
  expected[method].split('\n'

--
components: Tests
messages: 316287
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: test_cprofile should fail instead of displaying a message

___
Python tracker 

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

Re: Suggestion for a "data" object syntax

On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
> Right? Your issues with tabs aside, I think it is impossible to ignore the
> the readability improvement. Not even speaking of how
> many commas and bracket you need to type in the first case.

That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Why should this be a language feature? Why not just create a data file
and then load it, or use a triple quoted string and write your own
parser? What's the advantage of making this language syntax?

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

[issue32717] Document PEP 560


Change by Ivan Levkivskyi :


--
keywords: +patch
pull_requests: +6419
stage: needs patch -> patch review

___
Python tracker 

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

Re: Suggestion for a "data" object syntax

On Tue, May 8, 2018 at 10:15 AM, Steven D'Aprano
 wrote:
> On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:
>
>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>> 123"hello"
>> ab c + de f
>>
>> is a synonym for:
>>
>> data = (
>> (1, 2, 3, "hello") ,
>> (a, b, c + d, e, f ) )
>
> Last time you brought up this idea, you were told that it is ambiguous.
> Using whitespace alone, it is impossible to distinguish between
>
> a + b
>
> and
>
> a + b
>
>
> Can you see the difference? Of course not. That's the whole point. It is
> ambiguous. The first is a single item consisting of a plus b, and the
> second is two items consisting of a, following by unary plus b.

Can you be more precise what issue are you addressing?
Last time and this time I told it uses TAB character to
separate elements.

> There's also the problem that your syntax requires the *invisible*
> difference between tabs and spaces to be treated as syntactically
> meaningful.

What editor do you use? My editor can toggle tabs highlighting as arrows,
and I suppose almost any editor has good support for highlighting of
characters by search, etc. For NPP there are even plugins like Regex helper.

The only real issue I know that there may be no option to adjust the
minimal size for a tabulation, so it can become too small
in some rare cases, and there is the highlight function for that.

I never had problems with inputing tables - It seems you are having
an issue or may be it's even some personal pet-pieve.

>
> [...]
>> *The benefits is just as in above examples : readability and
>> 'typeability' boost.*
>
> But your syntax is not more readable, it is less readable and ambiguous.
> It requires us to care about the difference between two kinds of
> invisible whitespace.

Yes it requires you to care about tabulation - which many users already do
to improve readability in their code. As well as any software like
Matlab, Excel, etc presents matrices as tables.
So they are all making it "less readable", lol.
Ok Steven, you like the brackets and commas noise, that's
quite funny. Your opinion is heard, but I would be thankful if you'll
speak for yourself,
and not try to enforce your opinion with these "us", "for us".

Also you seem to start with cherry-picking straight away - trying
to find an issue and wind it up with the whole idea, totally ignoring
obvious benefits for most frequent use cases like multiline
strings,1d tuples/lists  and simple tables.
A very common table case is a 2-column table.

So you would prefer this:

L = (
(a, 1),
(b, 2),
(c, 3),
(foobar, 4))

over this:

L === T/T:
a1
b2
c3
foobar4

Right? Your issues with tabs aside, I think it is impossible to ignore the
the readability improvement. Not even speaking of how
many commas and bracket you need to type in the first case.

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

[issue33144] random._randbelow optimization


Change by Serhiy Storchaka :


--
resolution:  -> fixed
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

[issue33144] random._randbelow optimization


Serhiy Storchaka  added the comment:


New changeset ec1622d56c80d15740f7f8459c9a79fd55f5d3c7 by Serhiy Storchaka in 
branch 'master':
bpo-33144: Fix choosing random.Random._randbelow implementation. (GH-6563)
https://github.com/python/cpython/commit/ec1622d56c80d15740f7f8459c9a79fd55f5d3c7


--

___
Python tracker 

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

[issue33365] http/client.py does not print correct headers in debug


Change by Serhiy Storchaka :


--
nosy: +barry, r.david.murray
versions:  -Python 3.4, Python 3.5

___
Python tracker 

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

[issue33444] Memory leak/high usage on copy in different thread


Change by Serhiy Storchaka :


--
nosy: +bquinlan, pitrou

___
Python tracker 

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

EuroPython 2018: Call for Proposals (CFP) is open

2018-05-08 Thread M.-A. Lemburg

We’re looking for proposals on every aspect of Python: programming
from novice to advanced levels, applications and frameworks, or how
you have been involved in introducing Python into your
organization. EuroPython is a community conference and we are eager to
hear about your experience.


   * https://ep2018.europython.eu/en/call-for-proposals/ *


Please also forward this Call for Proposals to anyone that you feel
may be interested.


Important Notice: New Conference Layout
---

Please note that the conference layout has changed compared to
previous years, the main conference (talks) is now only three days:

* Monday and Tuesday:
trainings, workshops and Beginners’ Day only
* Wednesday, Thursday, Friday:
talks, panels, posters, helpdesks, open sessions, etc.
(no trainings!)


Submit your proposal


   * https://ep2018.europython.eu/en/call-for-proposals/ *

Submissions will be open until Sunday, May 20.

Given the compact timing this year, one should not bet on an
extension, please submit your proposals as early as possible - also to
reduce work load of the reviewers. Thank you.

Presenting at EuroPython


We will accept a broad range of presentations, from reports on
academic and commercial projects to tutorials and case studies. As
long as the presentation is interesting and potentially useful to the
Python community, it will be considered for inclusion in the program.

Can you show something new and useful? Can you show the attendees how
to: use a module? Explore a Python language feature? Package an
application? If so, please consider submitting a talk.

Submission types


* Regular Talk / approx. 110 slots
* Trainings / 12 slots.
* Panels
* Interactive
* Posters / 15 slots
* Helpdesk / 6 slots

Tracks
--

You may suggest your submission for a track. Tracks are groups of
talks, covering the same domain (e.g. Django), all in the same room in
a row. You may choose one of these specialized domains / tracks:

* Business Track (running a business, being a freelancer)
* DevOps
* Django Track
* Educational Track
* General Python
* Hardware/IoT Track
* PyData Track
* Science Track
* Web Track

PyData EuroPython 2018
--

As usual, there will be a PyData track at this year’s
conference.

The PyData track is run in cooperation with NumFocus and
the PyData Edinburgh meetup.

Discounts for Content Contributors
--

Since EuroPython is a not-for-profit community conference, it is not
possible to pay out rewards for talks or trainings.

For talks, posters, help desk and organizing a panels or interactive
sessions we will give out a 25% discount coupon valid for one
conference ticket.

Trainers will receive a 100% discount coupon for both a conference
ticket and a training pass to compensate for the longer preparation
time.

More details


Since there's a lot more detail to how the CFP works, please check the
CFP page for additional information:

   * https://ep2018.europython.eu/en/call-for-proposals/ *


Enjoy,
--
EuroPython 2018 Team
https://ep2018.europython.eu/
https://www.europython-society.org/


PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/993418719756996608
Thanks.

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

Support the Python Software Foundation:
http://www.python.org/psf/donations/

2019: Call for Papers & Call for Workshop Proposals

2018-05-08 Thread Fabio Niephaus

 2019 : The Art, Science, and Engineering of Programming

April 1-4, 2019, Genova, Italy
http://2019.programming-conference.org

The International Conference on the Art, Science, and Engineering of
Programming is a new conference focused on programming topics including the
experience of programming. We have named it  for short.
 seeks for papers that advance knowledge of programming on any
relevant topic, including programming practice and experience.
Paper submissions and publications are handled by the the Art, Science, and
Engineering of Programming journal (http://programming-journal.org).
Accepted papers must be presented at the conference.


  CALL FOR PAPERS


 2019 accepts scholarly papers that advance knowledge of
programming. Almost anything about programming is in scope, but in each
case there should be a clear relevance to the act and experience of
programming.

PAPER SUBMISSIONS: June 1, 2018
URL FOR SUBMISSIONS: http://programming-journal.org/submission/

Submissions covering several areas of expertise are accepted, including but
not limited to:

• General-purpose programming
• Distributed systems programming
• Parallel and multi-core programming
• Graphics and GPU programming
• Security programming
• User interface programming
• Database programming
• Visual and live programming
• Data mining and machine learning programming
• Interpreters, virtual machines and compilers
• Modularity and separation of concerns
• Model-based development
• Metaprogramming and reflection
• Testing and debugging
• Program verification
• Programming education
• Programming environments
• Social coding


  CALL FOR WORKSHOP PROPOSALS


To build a community and to foster an environment where participants can
exchange ideas and experiences related to practical software development,
 will host a number of workshops, during the days before the
main conference. The workshops will provide a collaborative forum to
exchange recent and/or preliminary results, to conduct intensive
discussions on a particular topic, or to coordinate efforts between
representatives of a technical community. They are intended as a forum for
lively discussion of innovative ideas, recent progress, or practical
experience on programming and applied software development in general for
specific aspects, specific problems, or domain-specific needs. We also
encourage practical, hands-on workshops in which participants actually
experience one or several aspects of practical software development.

WORKSHOP PROPOSAL SUBMISSIONS:
First Deadline: July 1st, 2018
Second Deadline: September 1st, 2018

The duration of workshops is in general one day, but we encourage the
submission of half-day workshop proposals on focused topics as well. In
exceptional situations, e.g., for workshops that involve actual practice of
programming-related activities, workshop organizers can request a 2 day
workshop slot. If desired, the workshop proceedings can be published in the
ACM Digital Library.


  IMPORTANT DATES


Research paper submissions: June 1, 2019
Research paper first notifications: August 1, 2018
Research paper final notifications: September 7, 2018

Workshop proposals: July 1st, 2018 (first deadline)
Workshop proposals: September 1st, 2018 (second deadline)



  ORGANIZATION


General Chair:
Davide Ancona, University of Genova

Local Organizing Chair:
Elena Zucca, University of Genova

Program Chair:
Matthew Flatt, University of Utah


Organizing Committee:

Walter Cazzola (Workshops Co-Chair), Università degli Studi di Milano
Stefan Marr (Workshops Co-Chair), University of Kent
Fabio Niephaus (Publicity Co-Chair), Hasso Plattner Institute, University
of Potsdam
Tobias Pape (Web Technology Chair), Hasso Plattner Institute, University of
Potsdam


Program Committee:

Mehdi Bagherzadeh, Oakland University
Walter Cazzola, Università degli Studi di Milano
Ravi Chugh, University of Chicago
Joeri De Koster, Vrije Universiteit Brussel
Christos Dimoulas, Northwestern University
Susan Eisenbach, Imperial College London
Richard P. Gabriel, Dream Songs, Inc. & HPI
Jeremy Gibbons, University of Oxford
Michael Greenberg, Pomona College
Philipp Haller, KTH Royal Institute of Technology
Robert Hirschfeld, HPI, University of Potsdam
Eunsuk Kang, Carnegie Mellon University
Stephen Kell, University of Cambridge
Stefan Marr, University of Kent
Tamara Rezk, Inria
Joshua Sunshine, Carnegie Mellon University
Steffen Zschaler, King's College London



 2019 is kindly supported by

Nikola v7.8.15 and v8.0.0b1 are out!

2018-05-08 Thread Chris Warrick

On behalf of the Nikola team, I am pleased to announce the immediate
availability of Nikola v7.8.15 and v8.0.0b1.

Nikola v7.8.15 is the last v7 maintenance release with a few more bug fixes.

Nikola v8.0.0b1 (Beta 1) is the first test release of the v8 series.
The v8 series adds a ton of new features and fixes bugs, while also
breaking backwards compatibility.

What is Nikola?
===

Nikola is a static site and blog generator, written in Python.
It can use Mako and Jinja2 templates, and input in many popular markup
formats, such as reStructuredText and Markdown — and can even turn
Jupyter (IPython) Notebooks into blog posts! It also supports image
galleries, and is multilingual. Nikola is flexible, and page builds
are extremely fast, courtesy of doit (which is rebuilding only what
has been changed).

Find out more at the website: https://getnikola.com/

Downloads
=

Install using `pip install Nikola==7.8.15`
or `pip install Nikola==8.0.0.beta1`.

Before upgrading to Nikola v8, make sure to read the “Upgrading”
document: https://getnikola.com/blog/upgrading-to-nikola-v8.html

Changes in v7.8.15
==

* Fix behavior for posts not available in default language
  (Issues #2956 and #3073)
* Fix behavior of RSS_PATH to do what the documentation
  says it does (Issue #3024)
* Use documented dateutil API for time zone list (Issue #3006)

Changes in v8.0.0b1
===

Important compatibility changes
---

* Rename ``crumbs.tmpl`` to ``ui_helper.tmpl`` and the breadcrumbs
  ``bar`` function to ``breadcrumbs`` (your templates may need
  changing as well)
* Rename ``post.is_mathjax`` to ``post.has_math``. Themes using
  ``post.is_mathjax`` must be updated; it is recommended that they are
  changed to use ``math_helper.tmpl``.
* Reading reST docinfo metadata, including first heading as title,
  requires ``USE_REST_DOCINFO_METADATA`` now (Issue #2987)
* RSS feeds might have changed their places due to ``RSS_PATH``
  behavior changes (you may need to change ``RSS_PATH``,
  ``RSS_FILENAME_BASE``)
* Atom feeds for archives and Atom pagination are no longer supported
  (Issue #3016)
* Sections are replaced by categories (Issue #2833)

Features


* Support hackerthemes.com themes and renamed bootswatch_theme command
subtheme (Issue #3049)
* Add ``DISABLE_MAIN_ATOM_FEED`` setting (Issue #3016, Issue #3039)
* Add ``ATOM_FILENAME_BASE`` setting (defaults to ``index`` for
  existing sites, but ``feed`` for new sites) (Issue #3016)
* Add ``CATEGORY_DESTPATH_AS_DEFAULT``, ``CATEGORY_DESTPATH_TRIM_PREFIX``,
  ``CATEGORY_DESTPATH_FIRST_DIRECTORY_ONLY`` settings, as part of
  replacing sections with categories (Issue #2833)
* Tags ``draft``, ``private`` and ``mathjax`` are no longer treated
  special if ``USE_TAG_METADATA`` is set to ``False`` (default for
  new sites) (Issue #2761)
* Replace ``draft`` and ``private`` tags with a ``status`` meta field
  (supports ``published``, ``featured``, ``draft``, ``private``)
  and ``mathjax`` with ``.. has_math: yes`` (Issue #2761)
* Rename ``TAG_PAGES_TITLES`` → ``TAG_TITLES``,
  ``TAG_PAGES_DESCRIPTIONS`` → ``TAG_DESCRIPTIONS``.
* Rename ``CATEGORY_PAGES_TITLES`` → ``CATEGORY_TITLES``,
  ``CATEGORY_PAGES_DESCRIPTIONS`` → ``CATEGORY_DESCRIPTIONS``.
* Produce a better error message when a template referenced in another
  template is missing (Issue #3055)
* Support captioned images and image ordering in galleries, as well as
  arbitrary metadata through a new ``metadata.yml`` file (Issue #3017,
  Issue #3050, Issue #2837)
* New ``ATOM_PATH`` setting (Issue #2971)
* Make ``crumbs`` available to all pages
* Allowing to customize RSS and Atom feed extensions with
  ``RSS_EXTENSION``, ``ATOM_EXTENSION`` settings (Issue #3041)
* Allowing to customize filename base appended to RSS_PATH
  with ``RSS_FILENAME_BASE`` setting (Issue #3041)
* Use basic ipynb template by default for slightly better appearance
  and behavior
* Fixing behavior of RSS_PATH to do what the documentation
  says it does (Issue #3024)
* Add support for fragments in path handlers (Issue #3032)
* New ``METADATA_VALUE_MAPPING`` setting to allow for flexible global
  modification of metadata (Issue #3025)
* New ``smartjoin`` template function/filter that joins lists and
  leaves strings as-is (Issue #3025)
* Explain index.html conflicts better (Issue #3022)
* Recognize both TEASER_END and (new) END_TEASER (Issue #3010)
  (warning: if you perform manual splits, the regex change means new
  indexes must be used)
* New MARKDOWN_EXTENSION_CONFIGS setting (Issue #2970)
* Replace ``flowr.js`` with ``justified-layout.js`` by Flickr
  (does not require jQuery!)
* ``bootblog4`` is the new default theme (Issue #2964)
* New ``bootstrap4`` and ``bootblog4`` themes (Issue #2964)
* New Thai translation by Narumol Hankrotha and Jean Jordaan
* Support for Commento comment system (Issue #2773)
* New PRESERVE_ICC_PROFILES option to control whether ICC profiles are

ANN: PyScripter 3.4 released

2018-05-08 Thread pyscripter

PyScripter is a free and open-source Python Integrated Development Environment 
(IDE) created with the ambition to become competitive in functionality with 
commercial Windows-based IDEs available for other languages.  It is 
feature-rich, but also light-weight. 

The major new feature is the ability to switch Python versions without exiting 
PyScripter.  Support for virtual environments (venv and virtualenv) and conda 
distributions is provided out-of-the-box. 

See: 
Announcement: 
https://pyscripter.blogspot.gr/2018/05/pyscripter-v340-released.html 
Project hoe: https://github.com/pyscripter/pyscripter/ 
Features: https://github.com/pyscripter/pyscripter/wiki/Features 
Downloads: https://sourceforge.net/projects/pyscripter/files
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

ANN: SciPy 1.1.0 released

2018-05-08 Thread Pauli Virtanen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

On behalf of the SciPy development team I'm pleased to announce the
SciPy 1.1.0 release.

Sources and binary wheels can be found at
https://pypi.python.org/pypi/scipy
and at https://github.com/scipy/scipy/releases/tag/v1.1.0. 
To install with pip:

pip install scipy==1.1.0

Thanks to everyone who contributed to this release!


=
SciPy 1.1.0 Release Notes
=

SciPy 1.1.0 is the culmination of 7 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and better
documentation. There have been a number of deprecations and API changes
in this release, which are documented below. All users are encouraged to
upgrade to this release, as there are a large number of bug-fixes and
optimizations. Before upgrading, we recommend that users check that
their own code does not use deprecated SciPy functionality (to do so,
run your code with ``python -Wd`` and check for ``DeprecationWarning``
s). Our development attention will now shift to bug-fix releases on the
1.1.x branch, and on adding new features on the master branch.

This release requires Python 2.7 or 3.4+ and NumPy 1.8.2 or greater.

This release has improved but not necessarily 100% compatibility with
the `PyPy `__ Python implementation. For running on
PyPy, PyPy 6.0+ and Numpy 1.15.0+ are required.

New features


`scipy.integrate` improvements
- --

The argument ``tfirst`` has been added to the function
`scipy.integrate.odeint`. This allows odeint to use the same user
functions as `scipy.integrate.solve_ivp` and `scipy.integrate.ode` without
the need for wrapping them in a function that swaps the first two
arguments.

Error messages from ``quad()`` are now clearer.

`scipy.linalg` improvements
- ---

The function `scipy.linalg.ldl` has been added for factorization of
indefinite symmetric/hermitian matrices into triangular and block
diagonal matrices.

Python wrappers for LAPACK ``sygst``, ``hegst`` added in
`scipy.linalg.lapack`.

Added `scipy.linalg.null_space`, `scipy.linalg.cdf2rdf`,
`scipy.linalg.rsf2csf`.

`scipy.misc` improvements
- -

An electrocardiogram has been added as an example dataset for a
one-dimensional signal. It can be accessed through
`scipy.misc.electrocardiogram`.

`scipy.ndimage` improvements
- 

The routines `scipy.ndimage.binary_opening`, and
`scipy.ndimage.binary_closing` now support masks and different border
values.

`scipy.optimize` improvements
- -

The method ``trust-constr`` has been added to
`scipy.optimize.minimize`. The method switches between two
implementations depending on the problem definition. For equality
constrained problems it is an implementation of a trust-region
sequential quadratic programming solver and, when inequality constraints
are imposed, it switches to a trust-region interior point method. Both
methods are appropriate for large scale problems. Quasi-Newton options
BFGS and SR1 were implemented and can be used to approximate second
order derivatives for this new method. Also, finite-differences can be
used to approximate either first-order or second-order derivatives.

Random-to-Best/1/bin and Random-to-Best/1/exp mutation strategies were
added to `scipy.optimize.differential_evolution` as ``randtobest1bin``
and ``randtobest1exp``, respectively. Note: These names were already in
use but implemented a different mutation strategy. See `Backwards
incompatible changes <#backwards-incompatible-changes>`__, below. The
``init`` keyword for the `scipy.optimize.differential_evolution`
function can now accept an array. This array allows the user to specify
the entire population.

Add an ``adaptive`` option to Nelder-Mead to use step parameters adapted
to the dimensionality of the problem.

Minor improvements in `scipy.optimize.basinhopping`.

`scipy.signal` improvements
- ---

Three new functions for peak finding in one-dimensional arrays were
added. `scipy.signal.find_peaks` searches for peaks (local maxima) based
on simple value comparison of neighbouring samples and returns those
peaks whose properties match optionally specified conditions for their
height, prominence, width, threshold and distance to each other.
`scipy.signal.peak_prominences` and `scipy.signal.peak_widths` can directly
calculate the prominences or widths of known peaks.

Added ZPK versions of frequency transformations:
`scipy.signal.bilinear_zpk`, `scipy.signal.lp2bp_zpk`,
`scipy.signal.lp2bs_zpk`, `scipy.signal.lp2hp_zpk`,
`scipy.signal.lp2lp_zpk`.

Added `scipy.signal.windows.dpss`,
`scipy.signal.windows.general_cosine` and
`scipy.signal.windows.general_hamming`.

`scipy.sparse` improvements
- ---

Previously, the ``reshape`` method only worked on
`scipy.sparse.lil_matrix`, and in-place

ANN: gcc-python-plugin 0.16

2018-05-08 Thread David Malcolm

gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the
CPython interpreter within GCC, allowing you to write new compiler
warnings in Python, generate code visualizations, etc.

This releases adds support for gcc 7 and gcc 8 (along with continued
support for gcc 4.6, 4.7, 4.8, 4.9, 5 and 6).

The upstream location for the plugin has moved from fedorahosted.org to
https://github.com/davidmalcolm/gcc-python-plugin

Additionally, this release contains the following improvements:

* add gcc.RichLocation for GCC 6 onwards
* gcc.Location
  * add caret, start, finish attributes for GCC 7 onwards
  * add gcc.Location.offset_column() method

Tarball releases are available at:
  https://github.com/davidmalcolm/gcc-python-plugin/releases

Prebuilt-documentation can be seen at:
  http://gcc-python-plugin.readthedocs.org/en/latest/index.html


The plugin and checker are Free Software, licensed under the GPLv3 or
later.

Enjoy!
Dave Malcolm
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

ANN: pyftpdlib 1.5.4 released

2018-05-08 Thread Giampaolo Rodola'

Hello all,
I'm glad to announce the release of pyftpdlib 1.5.4:
https://github.com/giampaolo/pyftpdlib

About
=

Python FTP server library provides a high-level portable interface to
easily write very efficient, scalable and asynchronous FTP servers with
Python.

What's new
==

**Enhancements**

- #463: FTPServer class can now be used as a context manager.

**Bug fixes**

- #431: Ctrl-C doesn't exit `python -m pyftpdlib` on Windows.
- #436: ThreadedFTPServer.max_cons is evaluated threading.activeCount(). If
  the user uses threads of its own it will consume the number of max_cons.
- #447: ThreadedFTPServer and MultiprocessFTPServer do not join() tasks
which
  are no longer consuming resources.

Links
=

- Home page: https://github.com/giampaolo/pyftpdlib
- Download: https://pypi.python.org/pypi/pyftpdlib
- Documentation: http://pyftpdlib.readthedocs.io
- What's new: https://github.com/giampaolo/pyftpdlib/blob/master/HISTORY.rst

--

Giampaolo - http://grodola.blogspot.com
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue33399] site.abs_paths should handle None cached type


Change by Serhiy Storchaka :


--
nosy: +brett.cannon, eric.snow, ncoghlan
type:  -> behavior
versions: +Python 3.7, Python 3.8

___
Python tracker 

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

[issue33444] Memory leak/high usage on copy in different thread

2018-05-08 Thread MultiSosnooley


New submission from MultiSosnooley :

On linux (ubuntu 16.04, 18.04 tested) with python 3.6.5, 3.5.5 and 3.7-dev 
(windows is not affected) there is ~850Mb of memory used by python process at 
sleep point. Replacing `submit` `result` with plain function call causes normal 
~75Mb at sleep point.
Maybe it is linux side issue (or normal behavior).

--
components: Interpreter Core
files: test-memory-leak.py
messages: 316285
nosy: MultiSosnooley
priority: normal
severity: normal
status: open
title: Memory leak/high usage on copy in different thread
versions: Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47576/test-memory-leak.py

___
Python tracker 

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

[issue33419] Add functools.partialclass


Serhiy Storchaka  added the comment:

I'm -1 on this change. It looks as an uncommon case, and the correct general 
implementation is hard (it may be even more hard that it looked to me now). The 
stdlib should't provide an incomplete implementation which can be replaced with 
just three lines of code in a concrete case if the user doesn't care about 
subtle details.

--

___
Python tracker 

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

Re: Problem/bug with class definition inside function definition

2018-05-08 Thread Ned Batchelder


On 5/8/18 3:55 AM, Alexey Muranov wrote:
Sorry, i was confused.  I would say that this mostly works as 
expected, though the difference between


   x = 42

   class C:
   x = x  # Works

and

   def f2(a):
   class D:
   a = a  # Does not work <
   return D

is still surprising to me.

Otherwise, probably the solution with

   def f(a):
   _a = a
   class D:
   a = _a
   return D

is good enough, if Python does not allow to refer "simultaneously" to 
variables from different scopes if they have the same name.


Alexey.


I'm curious to see the real code you're writing that uses this style of 
class creation.  It feels like there might be an easier way to achieve 
your goal.


--Ned.



On Tue, 8 May, 2018 at 12:21 AM, Alexey Muranov 
 wrote:

To be more exact, i do see a few workarounds, for example:


   def f4(a):
   b = a
   class D:
   a = b  # Works
   return D

But this is not what i was hoping for.

Alexey.

On Tue, 8 May, 2018 at 12:02 AM, Alexey Muranov 
 wrote:
I have discovered the following bug or problem: it looks like i am 
forced to choose different names for class attributes and function 
arguments, and i see no workaround.  Am i missing some special 
syntax feature ?


Alexey.

---
x = 42

class C1:
   y = x  # Works

class C2:
   x = x  # Works

# ---
def f1(a):
   class D:
   b = a  # Works
   return D

def f2(a):
   class D:
   a = a  # Does not work <
   return D

def f3(a):
   class D:
   nonlocal a
   a = a  # Does not work either <
   return D

# ---
def g1(a):
   def h():
   b = a  # Works
   return b
   return h

def g2(a):
   def h():
   a = a  # Does not work (as expected)
   return a
   return h

def g3(a):
   def h():
   nonlocal a
   a = a  # Works
   return a
   return h

# ---
if __name__ == "__main__":
   assert C1.y == 42
   assert C2.x == 42

   assert f1(13).b == 13

   try:
   f2(13)  # NameError
   except NameError:
   pass
   except Exception as e:
   raise Exception( 'Unexpected exception raised: '
    '{}'.format(type(e).__name__) )
   else:
   raise Exception('No exception')

   try:
   f3(13).a  # AttributeError
   except AttributeError:
   pass
   except Exception as e:
   raise Exception( 'Unexpected exception raised: '
    '{}'.format(type(e).__name__) )
   else:
   raise Exception('No exception')

   assert g1(13)() == 13

   try:
   g2(13)()  # UnboundLocalError
   except UnboundLocalError:
   pass
   except Exception as e:
   raise Exception( 'Unexpected exception raised: '
    '{}'.format(type(e).__name__) )
   else:
   raise Exception('No exception')

   assert g3(13)() == 13







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

[issue33437] Defining init in enums

2018-05-08 Thread Andres Ayala


Andres Ayala  added the comment:

I see, with mixed types you need to use __new__ to construct the elements (I 
imagine is specially important for non mutable types)

I have modified the example of the coordinates to try to use a mixed type. Is 
not the most useful thing, but it mix the bytes class.
Is it not obvious how to correctly use the mixin + __new__ operator so it is 
easy that the example is not correct or can be done better.

class Coordinate(bytes, Enum):
"""
Coordinate with binary codes that can be indexed by the int code.
"""
def __new__(cls, value, label, unit):
obj = bytes.__new__(cls, [value])
obj._value_ = value
obj.label = label
obj.unit = unit
return obj

PX = (0, 'P.X', 'km')
PY = (1, 'P.Y', 'km')
VX = (2, 'V.X', 'km/s')
VY = (3, 'V.Y', 'km/s')


# This works as expected
for element in Coordinate:
print("{0}: {0.label}[{0.unit}] = {0.value}".format(element))

# And this Work
print("Obtain P.Y from the name:", Coordinate['PY'])
print("Obtain V.Y from the index:", Coordinate(3))

# This shall be False
print('Coordinate.PY == 1 is:', Coordinate.PY == 1)
# But this shall be True
print("Coordinate.PY == b'\\01' is:", Coordinate.PY == b'\01')

Thanks!

--

___
Python tracker 

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

[issue20104] expose posix_spawn(p)


Serhiy Storchaka  added the comment:

I propose the following changes to the file_actions parameter in PR 6725. 
Currently it is the fourth positional-only parameter with the default value 
None.

1. Change its default value to an empty tuple. None will no longer be accepted 
as a special case. This will simplify a mental model.

2. Since the order of parameters already doesn't math the natural order of the 
corresponding C function, and many other keyword-only parameters will be added 
in PR 6693, it makes sense to make file_actions a keyword-only parameter too.

--

___
Python tracker 

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

[issue20104] expose posix_spawn(p)


Change by Serhiy Storchaka :


--
pull_requests: +6418

___
Python tracker 

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

Re: itemgetter with default arguments

2018-05-08 Thread Antoon Pardon

On 07-05-18 17:45, Peter Otten wrote:
> Antoon Pardon wrote:
>
>> On 05-05-18 09:33, Peter Otten wrote:
>>> I think you have established that there is no straight-forward way to
>>> write this as a lambda. But is adding a default to itemgetter the right
>>> conclusion?
>>>
>>> If there were an exception-catching decorator you could write
>>>
>>> f = catch(IndexError, "spam")(itemgetter(2))
>> I think your catch function would be a usefull addition, but I don't see
>> it solving this problem once we use itemgetter te get multiple entries.
> Good catch()
>
> ;)
>
> The obvious way, expressing the n-tuple case in terms of the solution for 
> scalars
>
 f = lambda items: tuple(catch(IndexError, "spam")(itemgetter(i))(items) 
> for i in (2, 1, 5))
>>> f("abc")
> ('c', 'b', 'spam')
>
> is a bit too complex to inline -- and also inefficient. You'd be tempted to 
> factor out the repetetive parts
>
 f = lambda items, gets=[catch(IndexError, "spam")(itemgetter(i)) for i 
> in (2, 1, 5)]: tuple(get(items) for get in gets)
 f("abc")
> ('c', 'b', 'spam')
>
> and thus make it even less readable.
>
> That said -- grepping my code I'm a bit surprised to find only
>
> 17 itemgetter(0)
>  9 itemgetter(1)
>  1 itemgetter(1, 0)
>  1 itemgetter(*indices)
>
> Checking /usr/lib/python3/dist-packages it looks like the situation is 
> similar. I conclude that the most useful addition to the operator module 
> would be
>
> first = itemgetter(0)
> second = itemgetter(1)

The problem with looking for such uses, is that I am working on a lot of
legacy code written in 2.2. It needed few adaptions to still work in 2.7
but I didn't adapt the code to make use of all the new features. But looking
at sort statements, it seems I have (the equivallent of) the following

itemgetter(2)
itemgetter(3)
itemgetter(4)
itemgetter(slice(0,-1))

-- 
Antoon Pardon.

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

[issue33413] asyncio.gather should not use special Future

2018-05-08 Thread twisteroid ambassador


twisteroid ambassador  added the comment:

I would like to comment on the last observation about current_task().cancel(). 
I also ran into this corner case recently. 

When a task is cancelled from outside, by virtue of there *being something 
outside doing the cancelling*, the task being cancelled is not currently 
running, and that usually means the task is waiting at an `await` statement, in 
which case a CancelledError will be raised at this `await` statement the next 
time this task runs. The other possibility is that the task has been created 
but has not had a chance to run yet, and in this case the task is marked 
cancelled, and code inside the task will not run.

When one cancels a task from the inside by calling cancel() on the task object, 
the task will still run as normal until it reaches the next `await` statement, 
where a CancelledError will be raised. If there is no `await` between calling 
cancel() and the task returning, however, the CancelledError is never raised 
inside the task, and the task will end up in the state of done() == True, 
cancelled() == False, exception() == CancelledError. Anyone awaiting for the 
task will get a CancelledError without a meaningful stack trace, like this:

Traceback (most recent call last):
  File "cancel_self.py", line 89, in run_one
loop.run_until_complete(coro)
  File "C:\Program Files\Python36\lib\asyncio\base_events.py", line 467, in 
run_until_complete
return future.result()
concurrent.futures._base.CancelledError

This is the case described in the original comment.

I would also consider this a bug or at least undesired behavior. Since 
CancelledError is never raised inside the task, code in the coroutine cannot 
catch it, and after the task returns the return value is lost. For a coroutine 
that acquires and returns some resource (say asyncio.open_connection()), this 
means that neither the task itself nor the code awaiting the task can release 
the resource, leading to leakage.

I guess one should be careful not to cancel the current task from the inside.

--
nosy: +twisteroid ambassador

___
Python tracker 

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

Re: Problem/bug with class definition inside function definition

2018-05-08 Thread Alexey Muranov

Sorry, i was confused.  I would say that this mostly works as expected, 
though the difference between


   x = 42

   class C:
   x = x  # Works

and

   def f2(a):
   class D:
   a = a  # Does not work <
   return D

is still surprising to me.

Otherwise, probably the solution with

   def f(a):
   _a = a
   class D:
   a = _a
   return D

is good enough, if Python does not allow to refer "simultaneously" to 
variables from different scopes if they have the same name.


Alexey.


On Tue, 8 May, 2018 at 12:21 AM, Alexey Muranov 
 wrote:

To be more exact, i do see a few workarounds, for example:


   def f4(a):
   b = a
   class D:
   a = b  # Works
   return D

But this is not what i was hoping for.

Alexey.

On Tue, 8 May, 2018 at 12:02 AM, Alexey Muranov 
 wrote:
I have discovered the following bug or problem: it looks like i am 
forced to choose different names for class attributes and function 
arguments, and i see no workaround.  Am i missing some special 
syntax feature ?


Alexey.

---
x = 42

class C1:
   y = x  # Works

class C2:
   x = x  # Works

# ---
def f1(a):
   class D:
   b = a  # Works
   return D

def f2(a):
   class D:
   a = a  # Does not work <
   return D

def f3(a):
   class D:
   nonlocal a
   a = a  # Does not work either <
   return D

# ---
def g1(a):
   def h():
   b = a  # Works
   return b
   return h

def g2(a):
   def h():
   a = a  # Does not work (as expected)
   return a
   return h

def g3(a):
   def h():
   nonlocal a
   a = a  # Works
   return a
   return h

# ---
if __name__ == "__main__":
   assert C1.y == 42
   assert C2.x == 42

   assert f1(13).b == 13

   try:
   f2(13)  # NameError
   except NameError:
   pass
   except Exception as e:
   raise Exception( 'Unexpected exception raised: '
'{}'.format(type(e).__name__) )
   else:
   raise Exception('No exception')

   try:
   f3(13).a  # AttributeError
   except AttributeError:
   pass
   except Exception as e:
   raise Exception( 'Unexpected exception raised: '
'{}'.format(type(e).__name__) )
   else:
   raise Exception('No exception')

   assert g1(13)() == 13

   try:
   g2(13)()  # UnboundLocalError
   except UnboundLocalError:
   pass
   except Exception as e:
   raise Exception( 'Unexpected exception raised: '
'{}'.format(type(e).__name__) )
   else:
   raise Exception('No exception')

   assert g3(13)() == 13





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

Re: Module, Package

On Mon, 07 May 2018 09:53:45 -0700, Sharan Basappa wrote:

> I am a bit confused between module and package in Python. Does a module
> contain package or vice versa? When we import something in Python, do we
> import a module or a package?

The term "module" in Python has multiple meanings:

- a particular kind of object, types.ModuleType

- a single importable .py, .pyc etc file

A package is a logical collection of importable .py etc files, usually 
collected inside a single directory. When you import a module of a 
package, that gives you a module object.

Normally we would say that packages contain modules. For example, if you 
have this file structure:

library/
+-- __init__.py   # special file which defines a package
+-- widgets.py
+-- stuff/
+-- __init__.py
+-- things.py

then we have a package "library", which in turn contains a submodule 
"library.widgets", and a subpackage "library.stuff", which in turn 
contains a submodule "library.stuff.things".

Each of these lines imports a module object:

import library
import library.stuff
import library.stuff.things
import library.widgets

from library import widgets
from library.stuff import things

Effectively, "packages" relates to how you arrange the files on disk; 
"modules" relates to what happens when you import them.

-- 
Steve

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

Re: Suggestion for a "data" object syntax

On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:

> *Example 3. Two-dimensional tuple.*
> 
> data === T/T :
> 123"hello"
> ab c + de f
> 
> is a synonym for:
> 
> data = (
> (1, 2, 3, "hello") ,
> (a, b, c + d, e, f ) )

Last time you brought up this idea, you were told that it is ambiguous. 
Using whitespace alone, it is impossible to distinguish between

a + b

and 

a + b

Can you see the difference? Of course not. That's the whole point. It is 
ambiguous. The first is a single item consisting of a plus b, and the 
second is two items consisting of a, following by unary plus b.

The same applies to unary minus.

That problem *alone* kills this idea.

There's also the problem that your syntax requires the *invisible* 
difference between tabs and spaces to be treated as syntactically 
meaningful.

[...]
> *The benefits is just as in above examples : readability and
> 'typeability' boost.*

But your syntax is not more readable, it is less readable and ambiguous. 
It requires us to care about the difference between two kinds of 
invisible whitespace.

> To present nesting of elements of higher than 2 levels, normal Python
> syntax can be used for deeper nesting:

So not only does idea not give us any new benefit, it cannot even do what 
existing syntax can do. It is inferior to what Python already has, 
ambiguous, and hard to read.

-- 
Steve

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

[issue33096] ttk.Treeview.insert() does not allow to insert item with "False" iid