[issue31969] re.groups() is not checking the arguments

[Narendra]

Narendra  added the comment:

Hi Storchaka,

As per re.groups(), its should work as below:

groups([default])
Return a tuple containing all the subgroups of the match, from 1 up to however 
many groups are in the pattern. The default argument is used for groups that 
did not participate in the match; it defaults to None. (Incompatibility note: 
in the original Python 1.5 release, if the tuple was one element long, a string 
would be returned instead. In later versions (from 1.5.1 on), a singleton tuple 
is returned in such cases.)

For example:

>>> m = re.match(r"(\d+)\.(\d+)", "24.1632")
>>> m.groups()
('24', '1632')
If we make the decimal place and everything after it optional, not all groups 
might participate in the match. These groups will default to None unless the 
default argument is given:

>>> m = re.match(r"(\d+)\.?(\d+)?", "24")
>>> m.groups()  # Second group defaults to None.
('24', None)
>>> m.groups('0')   # Now, the second group defaults to '0'.
('24', '0')

I tested some scenario as below:
Scenario: Suppose i have a match like 
m = re.match(r"(\d+)\.(\d+)", "24.1632")
Here if i pass m.groups(1), then it should check if there is optional match 
(optional match, pattern which is specified using ?), it should print 1 in 
that match and if not, it should throw error that there is no any optional 
match (didn't have any pattern with ?).

Expected Output:
>>> m.groups(1)
There is no any optional argument to use 1

Received Output:
>>> m.groups(1)
'24', '1632')

Please review the above and provide your comments?

--
resolution: not a bug -> 
status: closed -> open

___
Python tracker 

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

[issue31977] threading.Condition can not work with threading.Semaphore

[张晓林]

Change by 张晓林 :


--
type: resource usage -> behavior

___
Python tracker 

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

Re: python3 byte decode

[Chris Angelico]

On Wed, Nov 8, 2017 at 4:36 PM, Ali Rıza KELEŞ  wrote:
>> To be more clear here, usually when humans say "identical" they mean having
>> exactly the same value or attributes.
>> Here, Chris means that the two strings are actually the same object rather
>> than two equivalent objects. "is" tests the former (the same object). "=="
>> is for testing the latter (the objects have the same value).
>
> Initially the 'is' compared returned value with None, I changed the
> code and it remained as is. After i have noticed this issue.
>
> Using `is` to compare with None  is OK, isn't it?

Yes, that's correct. None is a singleton, so you check for it by
identity. There are other uses of identity checks, such as:

if str is bytes:
# we're running Python 2, so encode/decode appropriately

if blah() is NotImplemented:
# use a fallback

But when you're working with strings or numbers, you'll generally want
to use equality checks.

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

[issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower than reference

[Benjamin Peterson]

Benjamin Peterson  added the comment:

@tiran, can we close this again?

--

___
Python tracker 

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

Re: python3 byte decode

[Ali Rıza KELEŞ]

Hi,

On 5 November 2017 at 04:06, Cameron Simpson  wrote:
> On 04Nov2017 01:47, Chris Angelico  wrote:
>>
>> On Fri, Nov 3, 2017 at 8:24 PM, Ali Rıza KELEŞ 
>> wrote:
>>>
>>> Yesterday, while working with redis, i encountered a strange case.
>>>
>>> I want to ask why is the following `True`
>>>
>>> ```
>>> "s" is b"s".decode()
>>> ```
>>>
>>> while the followings are `False`?
>>>
>>> ```
>>> "so" is b"so".decode()
>>> "som" is b"som".decode()
>>> "some" is b"some".decode()
>>> ```
>>>
>>> Or vice versa?
>>>
>>> I read that `is` compares same objects, not values. So my question is
>>> why "s" and b"s".decode() are same objects, while the others aren't?
>>>
>>> My python version is 3.6.3.


> For speed and memory reasons, Python notices small values of strings and
> ints, and allocates them only once. So When your write:
>
>  a = "s"
>  b = "s"
>
> Python will reuse the same str object for both. Because of this, not only is
> "a == b" (i.e. they have the same value) but also "a is b" (a and b refer to
> the same object). But this is not guarrenteed, and certainly for larger
> values Python doesn't bother. Eg:

Actually I guessed that it should be a caching mechanism or something
like, but i was not sure since I do not know python internals in
detail.


>> You shouldn't be comparing string objects with 'is'. Sometimes two
>> equal strings will be identical, and sometimes they won't. All you're
>> seeing is that the interpreter happened to notice and/or cache this
>> particular lookup.
>
>
> To be more clear here, usually when humans say "identical" they mean having
> exactly the same value or attributes.
> Here, Chris means that the two strings are actually the same object rather
> than two equivalent objects. "is" tests the former (the same object). "=="
> is for testing the latter (the objects have the same value).

Initially the 'is' compared returned value with None, I changed the
code and it remained as is. After i have noticed this issue.

Using `is` to compare with None  is OK, isn't it?

Cameron, Terry, Chris thanks for your replies in depth.

-
Ali Riza

>>
>>

>
>
>  a = "ghghghghghg"
>  b = "ghghghghghg"
>
> Here they will have the same value but be different objects. So "==" will
> still return True, but "is" would return False.
>
> You should usually be using "==" to compare things. "is" has its place, but
> it is usually not what you're after.
>
> In your example code, b"s".decode() returns the string value "s", and Python
> is internally deciding to reuse the existing "s" from the left half of your
> comparison. It can do this because strings are immutable. (For example, "+="
> on a string makes a new string).
>
> Hoping this is now more clear,
> Cameron Simpson  (formerly c...@zip.com.au)
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
--
Ali Rıza Keleş
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31977] threading.Condition can not work with threading.Semaphore

[张晓林]

New submission from 张晓林 :

the python document say Condition work will Locks, like RLock...

but i find it not work with Semaphore, because Condition._is_owned is like this

def _is_owned(self):
# Return True if lock is owned by current_thread.
# This method is called only if _lock doesn't have _is_owned().
if self._lock.acquire(0):
self._lock.release()
return False
else:
return True

this work for RLock, but not work for Semaphore, and Semaphore do not have it's 
own _is_owned implement.

i spend a lot of time on this issue. maybe fix it, or document it out?

--
messages: 305807
nosy: 张晓林
priority: normal
severity: normal
status: open
title: threading.Condition can not work with threading.Semaphore
type: resource usage
versions: Python 3.6

___
Python tracker 

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

[issue31971] idle_test: failures on x86 Windows7 3.x

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In build 129, which finished perhaps 3 hours ago, test_idle passed again.  I 
think we should merge the fix anyway in case 'hover' appears again on some 
machine.

A similar try:except is needed elsewhere.

--

___
Python tracker 

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

[issue31976] Segfault when closing BufferedWriter from a different thread

[Benjamin Fogle]

Change by Benjamin Fogle :


--
type:  -> crash

___
Python tracker 

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

[issue31971] idle_test: failures on x86 Windows7 3.x

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The failure in tearDownClass is a side-effect of the failure in test_set_keys 
causing 'p.set_keys_type = Func' being skipped.  That could be prevented with 
'try:finally: p.set_keys_type = Func'.

I am completely puzzled at the sudden failure on one machine.  configdialog and 
test_configdialog were lasted changed 11 days ago (10/27) by Serhey's patch to 
make font samples editable.  test_idle passed consistently everywhere, 
including that machine, until build 121, 16 hours ago, and then suddenly 
started failing, consistently, on that one machine (as far as I know).  It 
continues to pass on my Win 10 machine, freshly updated with Python rebuilt.  I 
also checked the git log for tkinter.__init__ and tkinter.ttk and they have not 
been changed either.

The failure message is also a surprise.  'custom_keyset_on' is a ttk 
Radiobutton.
https://docs.python.org/3/library/tkinter.ttk.html#widget-states
does not list 'hover' as a state.  However
https://www.tcl.tk/man/tcl8.6/TkCmd/ttk_widget.htm#M-state
does (so the doc needs fixing): "The mouse cursor is within the widget."

Perhaps 'hover' is a result of previous mouse cursor positioning from 
event_generates in the font tab test.  (Why the sudden change on one system 
would still be a puzzle.)  If this is the reason, then I only need to worry 
about this one state test.

Otherwise, I would have to think about either parking the cursor where it 
cannot interfere, or about minimizing the dialog when it does not need to be 
de-iconified for event_generate to work.

Serhiy, any thoughts on this?

--
assignee:  -> terry.reedy
components: +IDLE
nosy: +serhiy.storchaka
type:  -> behavior
versions: +Python 3.6

___
Python tracker 

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

[issue31976] Segfault when closing BufferedWriter from a different thread

[Benjamin Fogle]

Change by Benjamin Fogle :


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

___
Python tracker 

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

[issue31975] Add a default filter for DeprecationWarning in __main__

[Éric Araujo]

Éric Araujo  added the comment:

This can’t be backported, but could the docs of 2.7 and stable 3.x version gain 
an example of equivalent PYTHONWARNINGS envvar?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue31976] Segfault when closing BufferedWriter from a different thread

[Benjamin Fogle]

New submission from Benjamin Fogle :

To reproduce:
```
import threading
import io
import time
import _pyio

class MyFileIO(io.FileIO):
def flush(self):
# Simulate a slow flush. Slow disk, etc.
time.sleep(0.25)
super().flush()

raw = MyFileIO('test.dat', 'wb')
#fp = _pyio.BufferedWriter(raw)
fp = io.BufferedWriter(raw)
t1 = threading.Thread(target=fp.close)
t1.start()
time.sleep(0.1) # Ensure t1 is sleeping in fp.close()/raw.flush()
fp.write(b'test')
t1.join()
```

_pyio.BufferedWriter ignores the error completely rather than throwing a 
ValueError("write to closed file").

--
components: Interpreter Core
messages: 305803
nosy: benfogle
priority: normal
severity: normal
status: open
title: Segfault when closing BufferedWriter from a different thread
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue31971] idle_test: failures on x86 Windows7 3.x

[Terry J. Reedy]

Change by Terry J. Reedy :


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

___
Python tracker 

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

[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args

[Anders Lorentsen]

Anders Lorentsen  added the comment:

While researching this, I discovered that on MS Windows

>>> subprocess.run([pathlike_object, additional_arguments])

did not run like it did on Posix. My PR includes this problem and it's fix.

--

___
Python tracker 

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

[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue31975] Add a default filter for DeprecationWarning in __main__

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue31975] Add a default filter for DeprecationWarning in __main__

[Nick Coghlan]

New submission from Nick Coghlan :

As per the post at 
https://mail.python.org/pipermail/python-dev/2017-November/150366.html, this is 
an RFE to cover adding a new warning filter to the default set:

once::DeprecationWarning:__main__

This means that all deprecation warnings triggered directly by code in __main__ 
will start being reported again, while deprecation warnings triggered by 
imported modules will continue to be ignored by default.

Thus the following will start emitting DeprecationWarning by default again (as 
they did in 2.6 and earlier):

- experiments at the REPL
- directly executed scripts
- modules executed with the -m switch
- pkg.__main__ submodules executed with the -m switch
- __main__.py files in executed directories and zip archives

However, any code *imported* from these will not trigger warnings.

This means that the following still won't trigger any warnings by default:

- modules imported & functions called from entry point wrapper scripts
- modules imported & functions called from pkg.__main__ submodules
- modules imported & functions called from __main__.py files

The intent behind the change is that it should be much harder for developers 
and educators to miss seeing a deprecation warning at least once for a 
deprecated API, while still silencing deprecation warnings by default for 
deployed Python applications.

--
messages: 305801
nosy: alex, gvanrossum, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a default filter for DeprecationWarning in __main__
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

[issue31974] Cursor misbahavior with Tkinter 3.6.1/tk 8.5 Text on Mac Sierra

[Terry J. Reedy]

New submission from Terry J. Reedy :

MacOS Sierra 10.12.6, Python 3.6.1, tk 8.5.15 or .18.  Consider this code with 
arbitrary compound statements and therefore indented lines.

for i in range(10):
if i%2:
print(f(i))

Irv Kalb on idle-dev thread 'Bug in cursor placement in IDLE editor' windows 
reports the following obnoxious behavior: click just to left or on left side of 
'p' and cursor appears on left margin.  Keep clicking and cursor moves right 
one space at a time until arriving next to 'p', where it should immediately go, 
and does on Windows, and, I presume, elsewhere.  (When the cursor first arrives 
at 'p', there is also the double-click selection highlight.)

At my suggestion, he also tested with code inserted directly in a tk Test 
window with this:

import tkinter as tk
root = tk.Tk()
text = tk.Text(root)
sample = '''

'''
text.insert('1.0', sample)
text.pack()
root.mainloop()

and encountered the same bug.  (Hence, this is not an IDLE issue.)The only 
difference is that clicking beside keyword 'if' does not show bug in IDLE but 
does in Text.  He also uploaded an unlisted video to YouTube.
https://www.youtube.com/watch?v=Us8px0BY5rg

Irv's current workaround is to click a letter or two to the right and use <-- 
key.

I realize that this is likely not a tkinter issue either, but I wanted to 
record it and get you two's thoughts.  Is this more likely to be a problem with 
a particular installation, or with at least one macOS release and even 8.5.18.

If the latter, can Irv install Python compiled elsewhere to work with 8.6?  
Ned, do you have a recommendation?

Kevin Walzer reported that he does not see the issue with Python built to run 
with 8.6 and using 8.6.7.  He noted that 8.5.18 does not get bug fixes.  I 
presume that this applies to 8.5 in general.  Will 3.7.0 be compiled for 8.6?

--
messages: 305800
nosy: IrvKalb, ned.deily, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: Cursor misbahavior with Tkinter 3.6.1/tk 8.5 Text on Mac Sierra
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue24132] Direct sub-classing of pathlib.Path

[Stephen M. Gava]

Stephen M. Gava  added the comment:

Using a set of paths with special properties and formats in a project, thought 
"the cleanest oop way to do this is try out python's oop paths in pathlib". 
Subclassed Path to implement my extra (non platfor specific) properties and 
fell at the first hurdle because of this issue... 

for me pathlib does not provide oop paths if i can't subclass Path, for 
whatever reason.

reverted to treating paths as strings and writing functions to handle my 
special path properties and formats.

i was also surprised when i found another bug report on this issue that said it 
was closed for 3.7, great i thought this has been solved, but no, the other 
report was closed because it was about the same issue as this ancient report.

--
nosy: +elguavas

___
Python tracker 

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

[issue25862] TextIOWrapper assertion failure after read() and SEEK_CUR

[Zackery Spytz]

Change by Zackery Spytz :


--
nosy: +ZackerySpytz
versions: +Python 3.6, Python 3.7 -Python 3.5

___
Python tracker 

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

Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Ian Kelly]

On Tue, Nov 7, 2017 at 4:28 PM, Steve D'Aprano
 wrote:
> On Wed, 8 Nov 2017 04:28 am, Ian Kelly wrote:
>
>> Steve's manufactured interactive example ("manufactured" because
>> who really uses for-else interactively?  If I really care that much
>> about output formatting I'm going to put it in a script).
>
> Me. As I have said.
>
> I really don't appreciate you implying that I'm lying about that.

Sorry, I wasn't aware that you had said that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Steve D'Aprano]

On Wed, 8 Nov 2017 04:28 am, Ian Kelly wrote:

> Steve's manufactured interactive example ("manufactured" because
> who really uses for-else interactively?  If I really care that much
> about output formatting I'm going to put it in a script).

Me. As I have said.

I really don't appreciate you implying that I'm lying about that.

As for the question of whether anyone else uses it... that depends on whether
there is anyone else:

- using the REPL in an exploratory manner

- entering loops with more than, say, two or three lines on the fly

- that requires an additional block that has to run after the loop, without a
pause for input

- and they don't realise this until after they've started typing the loop
(it's *exploratory* coding, which means sometimes you haven't thought things
through until after you start typing)

- AND they have the insight to realise that you can use an else block to
rescue the situation without having to re-enter the lines already entered.


Given how unfamiliar for...else is, it's probably only a small number of
people that meet *all* these conditions, especially the last. I fear that
most people wouldn't have the insight to realise that you can do this --
because they either don't know for...else at all, or they have the wrong
mental model for it, or they simply aren't good at thinking outside the box.

Who knows what other "thinking outside the box" uses for for...else with no
break there are? Where there is one, there are probably others. The point is,
if you require break and make the absence a syntax error, you rule them out.

As things are today, the for block and the else block are loosely coupled.
Apart from the requirement that else must immediately follow a for (or while)
block, the language doesn't *force* there to be any coupling between the for
block and the else block. We may consider them to be separate blocks, almost
unrelated in principle (if not in practice).

That has the conceptual advantage that we can teach, learn and think about the
for and else blocks as separate concepts, which allows us to reason about
them by composition:

- we can reason about the for block as iteration over a sequence;

- if we now add an else block after it, we don't have to revise our reasoning
about the for block, we simply add the else block after it.

Which is why I was able to think outside the box and realise I could rescue my
already-typed dozen line for loop by adding an else clause.


Whereas Jon's model requires us to change our understanding of the for block:

- we reason about the for block as iteration;

- if we then add an else block, we have to go back and re-interpret the for
block as some sort of metaphorical search, whether or not it actually is a
search, before we can think about the else block. Otherwise it doesn't make
sense in his model of "search, else if not condition leading to break".

In Jon's model, if we interpret else as "else no break", then we're also left
with the mystery of what happened to the "if break" clause.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue31973] Incomplete DeprecationWarning for async/await keywords

[Jakub Wilk]

Change by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

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

[issue31973] Incomplete DeprecationWarning for async/await keywords

[Barry A. Warsaw]

New submission from Barry A. Warsaw :

Issue bpo-26182 added DeprecationWarnings for "import async" and "import await" 
since both of those pseudo-keywords were to become actual reserved keywords in 
Python 3.7.  This latter has now happened, but the fix in bpo-26182 is 
incomplete.  It does not trigger warnings on "from .async import foo".

base/
__init__.py
async.py
good.py

-async.py
x = 1

-good.py
from .async import x


$ python3.6 -W error::DeprecationWarning -c "import base.good"
$ python3.7 -c "import base.good"
Traceback (most recent call last):
  File "", line 1, in 
  File "/private/tmp/x1/base/good.py", line 1
from .async import x
  ^
SyntaxError: invalid syntax
$ cd base
$ python3.6 -W error::DeprecationWarning -c "import async"
DeprecationWarning: 'async' and 'await' will become reserved keywords in Python 
3.7

--
messages: 305798
nosy: barry
priority: normal
severity: normal
status: open
title: Incomplete DeprecationWarning for async/await keywords
versions: Python 3.6, Python 3.7

___
Python tracker 

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

Re: Ideas about how software should behave

[Ned Batchelder]

On 11/7/17 5:48 PM, Ben Finney wrote:

Ian Kelly  writes:


Nowadays I realize and accept that this is preposterous. You cannot
criticize an idea without also criticizing the people who are attached
to that idea.

Maybe so. Does that mean we must not criticise ideas? Later in your
message you say no, but everything leading up to it argues you think so.

In the thread which spawned this one, an idea was criticised, *because*
someone expressed attachment to the idea.

The idea was expressly one about software behaviour. Should that idea
not be criticised in this forum, because someone expressed attachment to
the idea?

Does this forum allow ideas to be criticised only if no-one is attached
to them?


Even if no personal slight is intended, it is received that way. If
your idea is bad, then by implication you are a person with bad ideas.

Yes. And people with bad ideas rarely abandon bad ideas if those ideas
are not shown to be bad.


Now, I'm not saying that we can't criticize ideas. We can, however,
choose to be polite or not in how we go about it.

Certainly. It is incivil to make personal attacks. The criticism which
started this sub-thread made no personal attack.

Yet you've already pointed out that criticism of an idea – an idea
specifically about how software should behave – is *perceived as* an
attack, by people who are attached to the idea.

You called such criticism “incivility”; presumably on the basis that the
person was attached to the idea that was criticised.

By responding, in this forum, to criticism of ideas with the
admonishment of “incivility”, you effectively imply that it is incivil
to criticise ideas strongly held — even when those ideas are about the
behaviour of Python software, in a forum whose purpose is discussion of
Python software.

This is the condescension of low expectation: that someone who is
attached to an idea deserves *less respect*, that they should not be
exposed to criticism of ideas they hold lest they perceive it as an
attack. That treats people as too fragile to examine an idea as separate
from their person.

I thoroughly reject that condescending attitude, and choose instead to
promote respect that people *can* examine ideas when those ideas are
criticised.

Ideas, whether lightly or strongly held, are never immune from
criticism. Indeed, for the purpose of reducing the amount of bad ideas
held by people, those ideas must be criticised.

Ideas about software behaviour, in this forum, are surely not an
exception to that.



All of this could have been avoided.  Steve called an idea arrogant. Jon 
felt that Steve was calling him arrogant. If Steve had simply said, "I'm 
sorry, I didn't mean that to apply to you," we wouldn't be here now. Why 
is it so hard to treat people as if they mattered?


People are so caught up in proving others wrong and themselves right, 
that just saying, "Sorry, I wasn't clear" feels like giving ground.


We need more civil discussion, and less sniping.  We're better than this.

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

[issue26692] cgroups support in multiprocessing

[Mihai Capotă]

Change by Mihai Capotă :


--
nosy: +mihaic

___
Python tracker 

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

[issue31957] [Windows] PCbuild error: A numeric comparison was attempted

[STINNER Victor]

STINNER Victor  added the comment:

Thank you Steve for the quick fix!

--
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: Ideas about how software should behave

[Ben Finney]

Ian Kelly  writes:

> Nowadays I realize and accept that this is preposterous. You cannot
> criticize an idea without also criticizing the people who are attached
> to that idea.

Maybe so. Does that mean we must not criticise ideas? Later in your
message you say no, but everything leading up to it argues you think so.

In the thread which spawned this one, an idea was criticised, *because*
someone expressed attachment to the idea.

The idea was expressly one about software behaviour. Should that idea
not be criticised in this forum, because someone expressed attachment to
the idea?

Does this forum allow ideas to be criticised only if no-one is attached
to them?

> Even if no personal slight is intended, it is received that way. If
> your idea is bad, then by implication you are a person with bad ideas.

Yes. And people with bad ideas rarely abandon bad ideas if those ideas
are not shown to be bad.

> Now, I'm not saying that we can't criticize ideas. We can, however,
> choose to be polite or not in how we go about it.

Certainly. It is incivil to make personal attacks. The criticism which
started this sub-thread made no personal attack.

Yet you've already pointed out that criticism of an idea – an idea
specifically about how software should behave – is *perceived as* an
attack, by people who are attached to the idea.

You called such criticism “incivility”; presumably on the basis that the
person was attached to the idea that was criticised.

By responding, in this forum, to criticism of ideas with the
admonishment of “incivility”, you effectively imply that it is incivil
to criticise ideas strongly held — even when those ideas are about the
behaviour of Python software, in a forum whose purpose is discussion of
Python software.

This is the condescension of low expectation: that someone who is
attached to an idea deserves *less respect*, that they should not be
exposed to criticism of ideas they hold lest they perceive it as an
attack. That treats people as too fragile to examine an idea as separate
from their person.

I thoroughly reject that condescending attitude, and choose instead to
promote respect that people *can* examine ideas when those ideas are
criticised.

Ideas, whether lightly or strongly held, are never immune from
criticism. Indeed, for the purpose of reducing the amount of bad ideas
held by people, those ideas must be criticised.

Ideas about software behaviour, in this forum, are surely not an
exception to that.

-- 
 \   “We jealously reserve the right to be mistaken in our view of |
  `\  what exists, given that theories often change under pressure |
_o__)  from further investigation.” —Thomas W. Clark, 2009 |
Ben Finney

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

[issue31824] Missing default argument detail in documentation of StreamReaderWriter

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +4284
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

[issue31486] calling a _json.Encoder object raises a SystemError in case obj.items() returned a tuple

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

bpo-28280 fixed this issue only in the master branch. I had left this issue 
open for fixing 3.6.

--
resolution: out of date -> 
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

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

[issue28791] update sqlite to latest version before beta 1

[Zachary Ware]

Zachary Ware  added the comment:

I'd say that's up to Ned and Benjamin.  It's a very simple backport at this 
point.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue31486] calling a _json.Encoder object raises a SystemError in case obj.items() returned a tuple

[Berker Peksag]

Berker Peksag  added the comment:

PR 3840 has been merged and it looks like Oren was correct. I'm getting the 
following output with current master:

>>> encoder(obj=BadDict({'spam': 42}), _current_indent_level=4)
['{}']

--
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

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

[issue31824] Missing default argument detail in documentation of StreamReaderWriter

[Berker Peksag]

Berker Peksag  added the comment:

For those who want to work on this issue: codecs.StreamReaderWriter 
documentation is located at Doc/library/codecs.rst.

--
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
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

Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Chris Angelico]

On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly  wrote:
> All of these are things that a linter should probably catch and warn
> about. If you had said that the break syntax suggestion was a good
> idea but probably better suited as a linter warning than as a
> SyntaxError integrated into the parser, then I would likely agree with
> you. That's not what you said, though. You said the suggestion was
> "ridiculous".

Someone did mention linters at one point, and if I didn't explicitly
agree, I certainly didn't disagree. Let me make my position clearer:

The suggestion that these should be hard errors in the parser is
ridiculous because it is not the parser's job to catch all bugs.
Python is not intended to be that sort of language. It is the job of a
linter to detect probable errors.

>> Not one of these is syntactically invalid. Why should "else without
>> break" be trapped by the parser? Your other examples mostly have good
>> parser-level reasons for being errors
>
> No, they don't. All four of them could just as easily also be accepted
> by the parser and only flagged as linter warnings.

If everyone in the world agreed that a tab was equal to eight spaces,
then I would agree that the tab/space discrepancy could be considered
a linter warning. But there's no such agreement, which means that
having the language declare some equivalency is extremely dangerous.
Py2 had several language features and misfeatures that are that
dangerous (having the simple name "input()" do evaluation is a trap
that MANY people have fallen into), and it's correct to fix that. If
Python had, from the start, treated tabs and spaces as different forms
of indentation, there would be no reason to change that now.

Whether True and False are keywords or builtins is a matter of debate,
but there are definite advantages to them being locked down, and the
only real disadvantage that I see is the question of consistency (eg
"Ellipsis" is not a keyword, so you can still assign to that).

Having star imports be bypassed when looking for nonlocals is going to
be extremely confusing if you DO import a name from the other module.
There's no right answer to the nonlocal lookup question, so the best
thing to do is to not permit it. There's fundamentally no way for this
to be both legal and sane in all situations, so it can't be left up to
the linter.

Mixing 'async def' and 'yield from' is, AIUI, more of a
NotImplementedError than a SyntaxError; the wording of the PEP
basically says that it's low priority, not that it's a bad thing. So
that one is never going to be flagged by a linter - once it's made
possible, it'll be the normal and expected behaviour, so there's no
reason to flag it (except perhaps as "beware that this is not backward
compatible with Python <3.8").

So, no, this is not the same.

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

Re: Easiest way to access C module in Python

[Gisle Vanem]

bartc wrote:


 From inside python 2.7:
   Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec  3 2016, 21:49:42) [MSC 
v.1500 32 bit (Intel)] on win32
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import life
   >>> dir(life)
   ['__builtins__', '__doc__', '__file__', '__name__', '__package__', 
'__test__']
   >>>

works fine.


Not really, as it's missing the attribute 'life' which is needed for the second 
part of 'life.life':


Not sure what happend there. All is working now. But as
you stated, Cython is truly a "beast".

But as I wrote to Lele privately, the main reason for the failure,
was Cygwin's Python2.7 messing up. I invoked the build from a GNU-Makefile.
Thus Cygwin's Python was picked up from /bin/bash instead of my regular
Python on PATH. A real PITA.

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

Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Ian Kelly]

On Tue, Nov 7, 2017 at 12:10 PM, Chris Angelico  wrote:
> On Wed, Nov 8, 2017 at 4:28 AM, Ian Kelly  wrote:
>> On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico  wrote:
>>> Maybe we're not defending the abuse of other contributors. Maybe we're
>>> defending a legitimate, if somewhat caustic, response to a ridiculous
>>> suggestion.
>>
>> I don't think it was a ridiculous suggestion.
>>
>> Assigment to False is a syntax error, even though it's lexically valid
>> and was accepted in the past.
>
> Assignment to None was and is a syntax error, and assignment to False
> was legal only for backward compatibility within the 2.x line. I'm not
> sure what your point is. None, False, and True are all keywords, not
> built-ins, so you can't assign to them (any more than you could assign
> to a literal integer).

That's a false equivalence. There is nothing about None, False or True
that *requires* them to be keywords, and my point is that in Python 2,
two out of the three were *not* keywords. Making them keywords was a
backward-incompatible change and entirely unnecessary, but it was done
because it was deemed to be worthwhile.

>> Inconsistent indentation is a syntax error, even though it could be
>> parsed and has been in the past.
>
> I'm not sure what you mean by "inconsistent" here, unless it's that
> tabs and spaces had a declared equivalency that they now don't.

Yes.

> Unindenting to a level you've never used has always been an error;
> being sloppy has never been:
>
> if 1:
> if 2:
> pass
>   pass # always an error
> if 3:
>  pass # never an error
>
> Again, though, I'm not sure what your point is. Are you saying that it
> was ridiculous (or called ridiculous) to separate tabs and spaces
> rather than treat them as equivalent? Or are you saying that it ought
> to be legal?

No, my point is not about indentation. I listed these things as
examples of useful syntax errors that are not unlike the for-else
syntax error suggestion. In this case, the change to treat tabs and
spaces separately for indentation was a good one, albeit backward
incompatible, and the suggestion to disallow for-else without break is
likewise a good one, albeit backward incompatible.

>> Wildcard imports inside a function are a syntax error, even though
>> it's lexically valid and mostly harmless.
>
> Mostly harmless? Hmm. Okay:
>
> def func1():
> spam = 1
> def func2():
> from module import *
> def func3():
> nonlocal spam
> spam += 1
>
> What does func3's spam refer to?

In my opinion, it should refer to the variable from func1, since the
star import can't be assumed to introduce a "spam" variable, and it
doesn't make sense for the meaning of the code (and the generated byte
code content) to depend on whether it does.

> I don't know for sure if that's why star imports got banned, but I
> also don't know for sure what should happen in the above situation
> either.

I think it's more likely because fast locals don't support dynamic
modification, the same reason why a call to exec() from a function
body can't modify the local variables either. It's not that this is
technically infeasible; it's just unsupported.

>> Using "yield from" inside an async coroutine is a syntax error, even
>> though it's lexically valid and "await" and "yield from" are nearly
>> identical.
>
> I'm not sure about this one, but the equivalence of await and yield
> from is a red herring. The part that's more surprising is this:
>
 async def foo():
> ...yield from [1,2,3]
> ...
>   File "", line 2
> SyntaxError: 'yield from' inside async function
 async def foo():
> ...for _ in [1,2,3]: yield _
> ...
>
> (Yes, I know "yield from" does a lot more than "for... yield" does)
>
> But in comparison to "for... break", this is definitely not an error
> on the basis that it "makes no sense". It's more likely to be an error
> because of some internal limitation, in the same way that async
> coroutines weren't possible _at all_ initially:

No, it isn't. They share implementation. The only difference between
the two apart from the syntactic restrictions is that await validates
the type of its argument and looks for a method called __await__
instead of __iter__; see PEP 492.

I suspect that the reason for the restriction was to reserve lexical
space for asynchronous generators to be supported in the future,
although PEP 525 only permits yield and not yield from, having
explicitly deferred yield from as "less critical" and "requiring
serious redesign".

>> I haven't seen any argument against making "else" without "break" a
>> syntax error that wouldn't also apply to the above, with the exception
>> of Steve's manufactured interactive example ("manufactured" because
>> who really uses for-else interactively? If I really care that much
>> about output formatting I'm going to put it in a script). If there is
>> any extant code that 

Re: Easiest way to access C module in Python

[bartc]

On 07/11/2017 20:08, Gisle Vanem wrote:

Lele Gaifax wrote:


On my PC, I get the following, using the "-v" option to verbosely see the
imported modules:

$ $ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
...

import life

dlopen("./life.so", 2);
import life # dynamically loaded from life.so

dir(life)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', 
'__test__', 'life']


Can you try to import the "life" module and print its "dir()" to see the
symbols it exposes?


 From inside python 2.7:
   Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec  3 2016, 21:49:42) 
[MSC v.1500 32 bit (Intel)] on win32

   Type "help", "copyright", "credits" or "license" for more information.
   >>> import life
   >>> dir(life)
   ['__builtins__', '__doc__', '__file__', '__name__', '__package__', 
'__test__']

   >>>

works fine.


Not really, as it's missing the attribute 'life' which is needed for the 
second part of 'life.life':


 But as I wrote, doing a:

   python -vc "import life; print(life.life())"


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

[issue31937] Add the term "dunder" to the glossary

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I never seen terms like "stir" or "inker", but the term "dunder" is used pretty 
widely. The glossary already contains abbreviations and Python folk terminology 
like EAFP and BDFL.

--

___
Python tracker 

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

Re: Ideas about how software should behave

[Grant Edwards]

On 2017-11-07, Chris Angelico  wrote:
> On Wed, Nov 8, 2017 at 6:44 AM, Stefan Ram  wrote:
>> Chris Angelico  writes:
>>>sure what your point is. None, False, and True are all keywords, not
>>>built-ins, so you can't assign to them (any more than you could assign
>>>to a literal integer).
>>
>> |Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit 
>> (AMD64)] on win32
>> |Type "help", "copyright", "credits" or "license" for more information.
>> |>>>
>> |>>> import ctypes
>> |>>>
>> |>>> value = 2
>> |>>> ob_ival_offset = ctypes.sizeof(ctypes.c_size_t) + 
>> ctypes.sizeof(ctypes.c_voidp)
>> |>>> ob_ival = ctypes.c_int.from_address(id(value)+ob_ival_offset)
>> |>>> ob_ival.value = 3
>> |>>>
>> |>>> print 2
>> |3
>
> That's still not assigning to a literal; that's mutating a cached
> object. There's a difference :)

True.

> Also, once you start messing with ctypes like this, all language
> guarantees are out the window.

In FORTRAN, the only language gurantees were

 1) When running your program, you'd almost, but not always, get all
of your cards back.

 2) The probability (P) of finding an available IBM 29 cardpunch was
approximately D**2 where D is how many day's you had left before
your deadline: with one hour left, P = 1/(24*24).

-- 
Grant Edwards grant.b.edwards Yow! LOOK!!  Sullen at American teens
  wearing gmail.com MADRAS shorts and
  "Flock of Seagulls" HAIRCUTS!

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

[issue31937] Add the term "dunder" to the glossary

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Agreed with Raymond that Python folk terminology should not go into the 
glossary.  I don't think I ever say "dunder" myself.

--
nosy: +pitrou

___
Python tracker 

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

[issue31951] import curses is broken on windows

[joe m]

joe m  added the comment:

I would much prefer the curses module to be supported in newer versions  since 
I believe that curses is installed as a built in module (not sure about that).

Anyhow, thank you for your help but I have found a replacement module called 
"asciimatics" which for fills all the functions that I really need.

--

___
Python tracker 

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

Re: Easiest way to access C module in Python

[Gisle Vanem]

Lele Gaifax wrote:


On my PC, I get the following, using the "-v" option to verbosely see the
imported modules:

$ $ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
...

import life

dlopen("./life.so", 2);
import life # dynamically loaded from life.so

dir(life)

['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__test__', 
'life']

Can you try to import the "life" module and print its "dir()" to see the
symbols it exposes?


From inside python 2.7:
  Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec  3 2016, 21:49:42) [MSC v.1500 
32 bit (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import life
  >>> dir(life)
  ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__test__']
  >>>

works fine. But as I wrote, doing a:
  python -vc "import life; print(life.life())"

from the cmd-line doesn't work:
  ...
  import life # dynamically loaded from life.pyd
  Traceback (most recent call last):
File "", line 1, in 
  AttributeError: 'module' object has no attribute 'life'
  ...

Inspection life.pyd shows no problems. It do export a "initlife"
function.

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

ANN: Wing Python IDE v. 6.0.8 released

[Wingware]

Hi,

We've just released Wing 6.0.8, a minor release that improves display of 
PEP 287 docstrings, fixes stability problems seen on Linux, fixes remote 
debugging of Django code, further improves remote development, adds some 
missing vi bindings, and makes about 30 other improvements.  For 
details, see https://wingware.com/pub/wingide/6.0.8/CHANGELOG.txt


Wing 6 is the latest major release in Wingware's family of Python IDEs, 
including Wing Pro, Wing Personal, and Wing 101.  Wing 6 adds many new 
features, introduces a new annual license option for Wing Pro, and makes 
Wing Personal free.


New Features in Wing 6

 * Improved Multiple Selections:  Quickly add selections and edit them
   all at once
 * Easy Remote Development:  Work seamlessly on remote Linux, OS X, and
   Raspberry Pi systems
 * Debugging in the Python Shell:  Reach breakpoints and exceptions in
   (and from) the Python Shell
 * Recursive Debugging:  Debug code invoked in the context of stack
   frames that are already being debugged
 * PEP 484 and PEP 526 Type Hinting:  Inform Wing's static analysis
   engine of types it cannot infer
 * Support for Python 3.6 and Stackless 3.4:  Use async and other new
   language features
 * Optimized debugger:  Run faster, particularly in multi-process and
   multi-threaded code
 * Support for OS X full screen mode:  Zoom to a virtual screen, with
   auto-hiding menu bar
 * Added a new One Dark color palette:  Enjoy the best dark display
   style yet
 * Updated French and German localizations:  Thanks to Jean Sanchez,
   Laurent Fasnacht, and Christoph Heitkamp

For a more detailed overview of new features see the release notice at 
https://wingware.com/news/2017-11-03


Annual License Option

Wing 6 adds the option of purchasing a lower-cost expiring annual 
license for Wing Pro.  An annual license includes access to all 
available Wing Pro versions while it is valid, and then ceases to 
function until it is renewed.  Pricing for annual licenses is US$ 
179/user for Commercial Use and US$ 69/user for Non-Commercial Use.


Perpetual licenses for Wing Pro will continue to be available at the 
same pricing.


The cost of extending Support+Upgrades subscriptions on Non-Commercial 
Use perpetual licenses for Wing Pro has also been dropped from US$ 89 to 
US$ 39 per user.


For details, see https://wingware.com/store/

Wing Personal is Free

Wing Personal is now free and no longer requires a license to run.  It 
now also includes the Source Browser, PyLint, and OS Commands tools, and 
supports the scripting API and Perspectives.


However, Wing Personal does not include Wing Pro's advanced editing, 
debugging, testing and code management features, such as remote 
development, refactoring, find uses, version control, unit testing, 
interactive debug probe, multi-process and child process debugging, move 
program counter, conditional breakpoints, debug watch, 
framework-specific support (for Jupyter, Django, and others), find 
symbol in project, and other features.


Links

Release notice: https://wingware.com/news/2017-11-03
Downloads and Free Trial: https://wingware.com/downloads
Buy: https://wingware.com/store/purchase
Upgrade: https://wingware.com/store/upgrade

Questions?  Don't hesitate to email us at supp...@wingware.com.

Thanks,

--

Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers

wingware.com

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

Re: Ideas about how software should behave

[Chris Angelico]

On Wed, Nov 8, 2017 at 6:44 AM, Stefan Ram  wrote:
> Chris Angelico  writes:
>>sure what your point is. None, False, and True are all keywords, not
>>built-ins, so you can't assign to them (any more than you could assign
>>to a literal integer).
>
> |Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)] 
> on win32
> |Type "help", "copyright", "credits" or "license" for more information.
> |>>>
> |>>> import ctypes
> |>>>
> |>>> value = 2
> |>>> ob_ival_offset = ctypes.sizeof(ctypes.c_size_t) + 
> ctypes.sizeof(ctypes.c_voidp)
> |>>> ob_ival = ctypes.c_int.from_address(id(value)+ob_ival_offset)
> |>>> ob_ival.value = 3
> |>>>
> |>>> print 2
> |3

That's still not assigning to a literal; that's mutating a cached
object. There's a difference :)

Also, once you start messing with ctypes like this, all language
guarantees are out the window.

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

Re: Ideas about how software should behave

[Grant Edwards]

On 2017-11-07, Stefan Ram  wrote:
> Chris Angelico  writes:
>>sure what your point is. None, False, and True are all keywords, not
>>built-ins, so you can't assign to them (any more than you could assign
>>to a literal integer).
>
>|Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)] 
>on win32
>|Type "help", "copyright", "credits" or "license" for more information.
>|>>>
>|>>> import ctypes
>|>>>
>|>>> value = 2
>|>>> ob_ival_offset = ctypes.sizeof(ctypes.c_size_t) + 
>ctypes.sizeof(ctypes.c_voidp)
>|>>> ob_ival = ctypes.c_int.from_address(id(value)+ob_ival_offset)
>|>>> ob_ival.value = 3
>|>>>
>|>>> print 2
>|3

I vaguely remember being able to do that in some implementations of
FORTRAN yonks ago:

   subroutine foo(i)
  i = 3
   end subroutine func

   [...]

   foo(2)

   write(*,*) 2

output would be:

3

-- 
Grant Edwards   grant.b.edwardsYow! If I pull this SWITCH
  at   I'll be RITA HAYWORTH!!
  gmail.comOr a SCIENTOLOGIST!

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

Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Chris Angelico]

On Wed, Nov 8, 2017 at 4:28 AM, Ian Kelly  wrote:
> On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico  wrote:
>> On Sat, Nov 4, 2017 at 11:25 PM, Jon Ribbens  
>> wrote:
>>> On 2017-11-04, Ben Finney  wrote:
 To respond to the criticism of an idea – criticism containing no mention
 of the person – as though it “clearly refers to the [person]”, is of
 significant concern on a software dicussion forum such as this.
>>>
>>> No, the thing that is "of significant conern on a software discussion
>>> forum such as this" is people such as yourself defending the abuse of
>>> other contributors.
>>
>> Maybe we're not defending the abuse of other contributors. Maybe we're
>> defending a legitimate, if somewhat caustic, response to a ridiculous
>> suggestion.
>
> I don't think it was a ridiculous suggestion.
>
> Assigment to False is a syntax error, even though it's lexically valid
> and was accepted in the past.

Assignment to None was and is a syntax error, and assignment to False
was legal only for backward compatibility within the 2.x line. I'm not
sure what your point is. None, False, and True are all keywords, not
built-ins, so you can't assign to them (any more than you could assign
to a literal integer).

> Inconsistent indentation is a syntax error, even though it could be
> parsed and has been in the past.

I'm not sure what you mean by "inconsistent" here, unless it's that
tabs and spaces had a declared equivalency that they now don't.
Unindenting to a level you've never used has always been an error;
being sloppy has never been:

if 1:
if 2:
pass
  pass # always an error
if 3:
 pass # never an error

Again, though, I'm not sure what your point is. Are you saying that it
was ridiculous (or called ridiculous) to separate tabs and spaces
rather than treat them as equivalent? Or are you saying that it ought
to be legal?

> Wildcard imports inside a function are a syntax error, even though
> it's lexically valid and mostly harmless.

Mostly harmless? Hmm. Okay:

def func1():
spam = 1
def func2():
from module import *
def func3():
nonlocal spam
spam += 1

What does func3's spam refer to?

I don't know for sure if that's why star imports got banned, but I
also don't know for sure what should happen in the above situation
either.

> Using "yield from" inside an async coroutine is a syntax error, even
> though it's lexically valid and "await" and "yield from" are nearly
> identical.

I'm not sure about this one, but the equivalence of await and yield
from is a red herring. The part that's more surprising is this:

>>> async def foo():
...yield from [1,2,3]
...
  File "", line 2
SyntaxError: 'yield from' inside async function
>>> async def foo():
...for _ in [1,2,3]: yield _
...

(Yes, I know "yield from" does a lot more than "for... yield" does)

But in comparison to "for... break", this is definitely not an error
on the basis that it "makes no sense". It's more likely to be an error
because of some internal limitation, in the same way that async
coroutines weren't possible _at all_ initially:

Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async def foo(): yield 1
...
  File "", line 1
SyntaxError: 'yield' inside async function

That's no longer a SyntaxError as of 3.6, and I suspect that making
"yield from" work inside an async function is, if not actually on the
roadmap, certainly a possibility.

> I haven't seen any argument against making "else" without "break" a
> syntax error that wouldn't also apply to the above, with the exception
> of Steve's manufactured interactive example ("manufactured" because
> who really uses for-else interactively? If I really care that much
> about output formatting I'm going to put it in a script). If there is
> any extant code that would actually be broken by this, it's very
> likely buggy.

There are many MANY constructs that are broadly useless.

Global declaration without assignment:
>>> def foo():
... global print
... print("hello")
...

Unused variable (often indicates a misspelling):
>>> def bar():
... x = 1
... return y
...

Never-executed bodies:
>>> def spam():
... if False: print("ham")
... while False: print("ham")
... for _ in []: print("ham")
... try: pass
... except ZeroDivisionError: print("ham")
...

(In CPython 3.7, the optimizer will eliminate the first two, but not
the for or try. That could change, of course.)

Not one of these is syntactically invalid. Why should "else without
break" be trapped by the parser? Your other examples mostly have good
parser-level reasons for being errors (you could argue from a language
design POV about why False is a keyword but Ellipsis is just a
built-in, but it's obvious that assigning to keywords has 

Re: Easiest way to access C module in Python

[Lele Gaifax]

Gisle Vanem  writes:

> python.exe -c "import life; print(life.life())"
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'module' object has no attribute 'life'
>
> Can you give a hint?

I tried with Python 2, and the same recipe works for me, on GNU/Linux:

$ python -c "import life; print life.life()"
42

I'm sorry, but I have no opportunity to try on a M$Windows system.

Anyway, is your interpreter able to load the extension module produced by the
"setup.py build_ext" step?

On my PC, I get the following, using the "-v" option to verbosely see the
imported modules:

$ $ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
...
>>> import life
dlopen("./life.so", 2);
import life # dynamically loaded from life.so
>>> dir(life)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__test__', 
'life']

Can you try to import the "life" module and print its "dir()" to see the
symbols it exposes?

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset ac4f6d4448fb6f9affb817bafb8357450fe43349 by Andrew Svetlov (Miss 
Islington (bot)) in branch '3.6':
bpo-31620: have asyncio/queues not leak memory when you've exceptions during 
waiting (GH-3813) (#4326)
https://github.com/python/cpython/commit/ac4f6d4448fb6f9affb817bafb8357450fe43349


--

___
Python tracker 

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

[issue31972] Inherited docstrings for pathlib classes are confusing

[Éric Araujo]

New submission from Éric Araujo :

pydoc pathlib.Path shows the docstring of PurePath:

 |  PurePath represents a filesystem path and offers operations which
 |  don't imply any actual filesystem I/O.

But immediately after we see methods like chmod, exists and co which obviously 
aren’t pure.  Looking at the reST docs or the source code, the reader can 
deduce that this is the docstring of PurePath inherited by Path, but I find it 
confusing.

Solution: adding docstrings to all pathlib classes.  PurePath and Path can have 
all the info, Posix/Windows* subclasses only one line with a reference.

--
components: Library (Lib)
keywords: easy
messages: 305788
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Inherited docstrings for pathlib classes are confusing
type: enhancement
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue31425] Expose AF_QIPCRTR in socket module

[Christian Heimes]

Change by Christian Heimes :


--
assignee:  -> christian.heimes
nosy: +christian.heimes

___
Python tracker 

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

Re: Easiest way to access C module in Python

[Gisle Vanem]

Lele Gaifax wrote:


$ python setup.py build_ext --inplace
Compiling life.pyx because it changed.
[1/1] Cythonizing life.pyx
running build_ext
building 'life' extension
creating build
creating build/temp.linux-x86_64-3.6
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ct/include 
-I/usr/include/python3.6m -c life.c -o build/temp.linux-x86_64-3.6/life.o
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-g -fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/tmp/ct/include 
-I/usr/include/python3.6m -c fred.c -o build/temp.linux-x86_64-3.6/fred.o
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro 
-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -g 
-fdebug-prefix-map=/build/python3.6-5reRaQ/python3.6-3.6.3=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-x86_64-3.6/life.o build/temp.linux-x86_64-3.6/fred.o -o 
/tmp/ct/life.cpython-36m-x86_64-linux-gnu.so
$ python -c "import life; print(life.life())"
42


I tried your example on Python 2.7 (Win-10 / MSVC), but failed:

python.exe setup.py build_ext --inplace
running build_ext
building 'life' extension
creating build
creating build\temp.win32-2.7
creating build\temp.win32-2.7\Release
f:\gv\VC_2017\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\cl.exe /c /nologo /Ox 
/MD /W3 /GS- /DNDEBUG
-If:\ProgramFiler\Python27\include -If:\ProgramFiler\Python27\PC /Tclife.c 
/Fobuild\temp.win32-2.7\Release\life.obj
life.c
f:\gv\VC_2017\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\cl.exe /c /nologo /Ox 
/MD /W3 /GS- /DNDEBUG
-If:\ProgramFiler\Python27\include -If:\ProgramFiler\Python27\PC /Tcfred.c 
/Fobuild\temp.win32-2.7\Release\fred.obj
fred.c
f:\gv\VC_2017\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\link.exe /DLL /nologo 
/INCREMENTAL:NO
/LIBPATH:f:\ProgramFiler\Python27\libs /LIBPATH:f:\ProgramFiler\Python27\PCbuild
/EXPORT:initlife build\temp.win32-2.7\Release\life.obj 
build\temp.win32-2.7\Release\fred.obj
/OUT:F:\ProgramFiler\Python27\test\Cython-test2\life.pyd 
/IMPLIB:build\temp.win32-2.7\Release\life.lib
/MANIFESTFILE:build\temp.win32-2.7\Release\life.pyd.manifest
   Creating library build\temp.win32-2.7\Release\life.lib and object 
build\temp.win32-2.7\Release\life.exp

python.exe -c "import life; print(life.life())"
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'life'


Can you give a hint?

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

Re: Easiest way to access C module in Python

[Rob Gaddi]

On 11/06/2017 05:59 PM, Grant Edwards wrote:

On 2017-11-06, John Pote  wrote:


I have successfully used Python to perform unit and integration tests in
the past and I'd like to do the same for some C modules I'm working with
at work. There seem to be a number of ways of doing this but being busy
at work and home I looking for the approach with the least learning curve.


When I want to test C modules (usually destined for an embedded
system) using a Python framework, I use ctypes.

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



I'll second ctypes.  It's pretty straightforward and I've made it do 
some very heavy lifting over the years.  Cython is definitely more work. 
 SWIG makes sense if you've got a huge number of interfaces you're trying
to map and need to automate the process, but if you've got south of 20 
I'd just do it natively with ctypes.


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

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4283

___
Python tracker 

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

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset c62f0cb3b1f6f9ca4ce463b1c99b0543bdfa38d6 by Andrew Svetlov (Suren 
Nihalani) in branch 'master':
bpo-31620: have asyncio/queues not leak memory when you've exceptions during 
waiting (#3813)
https://github.com/python/cpython/commit/c62f0cb3b1f6f9ca4ce463b1c99b0543bdfa38d6


--
nosy: +asvetlov

___
Python tracker 

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

Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Ian Kelly]

On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico  wrote:
> On Sat, Nov 4, 2017 at 11:25 PM, Jon Ribbens  
> wrote:
>> On 2017-11-04, Ben Finney  wrote:
>>> To respond to the criticism of an idea – criticism containing no mention
>>> of the person – as though it “clearly refers to the [person]”, is of
>>> significant concern on a software dicussion forum such as this.
>>
>> No, the thing that is "of significant conern on a software discussion
>> forum such as this" is people such as yourself defending the abuse of
>> other contributors.
>
> Maybe we're not defending the abuse of other contributors. Maybe we're
> defending a legitimate, if somewhat caustic, response to a ridiculous
> suggestion.

I don't think it was a ridiculous suggestion.

Assigment to False is a syntax error, even though it's lexically valid
and was accepted in the past.

Inconsistent indentation is a syntax error, even though it could be
parsed and has been in the past.

Wildcard imports inside a function are a syntax error, even though
it's lexically valid and mostly harmless.

Using "yield from" inside an async coroutine is a syntax error, even
though it's lexically valid and "await" and "yield from" are nearly
identical.

I haven't seen any argument against making "else" without "break" a
syntax error that wouldn't also apply to the above, with the exception
of Steve's manufactured interactive example ("manufactured" because
who really uses for-else interactively? If I really care that much
about output formatting I'm going to put it in a script). If there is
any extant code that would actually be broken by this, it's very
likely buggy.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31937] Add the term "dunder" to the glossary

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

Thanks Raymond. +1 for adding the above list. 

I don't think FAQ is the right place either, I prefer we don't have to add the 
entries in the form of questions & answers.

--

___
Python tracker 

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

Re: Ideas about how software should behave (was: replacing `else` with `then` in `for` and `try`)

[Ian Kelly]

On Fri, Nov 3, 2017 at 11:55 PM, Ben Finney  wrote:
> Ian Kelly  writes:
>
>> Please stop defending the use of incivility on this list.
>
> Please stop conflating people, who deserve civility, with ideas. We must
> not allow the civility deserved by people, to prevent us from
> criticising any ideas — especially not ideas about the behaviour of
> software.

No, I won't. I once believed this, too. I used it as a defense for
criticism of religious ideas. "Oh, I'm not attacking the believers in
religion. I'm attacking the *ideas* of religion." And I meant it, too:
I wasn't *trying* to insult anybody when I would say that religious
belief was foolish and ignorant.

Nowadays I realize and accept that this is preposterous. You cannot
criticize an idea without also criticizing the people who are attached
to that idea. Even if no personal slight is intended, it is received
that way. If your idea is bad, then by implication you are a person
with bad ideas.

Now, I'm not saying that we can't criticize ideas. We can, however,
choose to be polite or not in how we go about it.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31793] Allow to specialize smart quotes in documentation translations

[INADA Naoki]

INADA Naoki  added the comment:

Thanks, Julien.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

___
Python tracker 

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

[issue31970] asyncio debug mode is very slow

[Yury Selivanov]

Yury Selivanov  added the comment:

Thank you for helping with asyncio!  I'll try to get to that transport 
performance issues you found sometime this week.  I've a few ideas how to add 
0-copy support to protocols.

--

___
Python tracker 

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

[issue31793] Allow to specialize smart quotes in documentation translations

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 64f10492dcda4117ac06399ae46ab645cb09b19e by INADA Naoki (Miss 
Islington (bot)) in branch '3.6':
bpo-31793: Doc: Specialize smart-quotes for Japanese (GH-4006)
https://github.com/python/cpython/commit/64f10492dcda4117ac06399ae46ab645cb09b19e


--

___
Python tracker 

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

[issue31793] Allow to specialize smart quotes in documentation translations

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 47eaaa55247b6ad8ae507c0048509c2e3db79bf0 by INADA Naoki (Miss 
Islington (bot)) in branch '2.7':
bpo-31793: Doc: Specialize smart-quotes for Japanese (GH-4006)
https://github.com/python/cpython/commit/47eaaa55247b6ad8ae507c0048509c2e3db79bf0


--

___
Python tracker 

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

[issue31970] asyncio debug mode is very slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset d8d218ffda6b7569625ff9edadbbc9a2b1055e32 by Antoine Pitrou in 
branch '3.6':
[3.6] bpo-31970: Reduce performance overhead of asyncio debug mode. (GH-4314) 
(#4322)
https://github.com/python/cpython/commit/d8d218ffda6b7569625ff9edadbbc9a2b1055e32


--

___
Python tracker 

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

[issue31970] asyncio debug mode is very slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thank you for the quick reviews!

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

[issue31793] Allow to specialize smart quotes in documentation translations

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4282

___
Python tracker 

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

[issue31793] Allow to specialize smart quotes in documentation translations

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4281

___
Python tracker 

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

[issue31793] Allow to specialize smart quotes in documentation translations

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 5a66c8a64d180b5f3c80307924adaec53cc8faa3 by INADA Naoki (Julien 
Palard) in branch 'master':
bpo-31793: Doc: Specialize smart-quotes for Japanese (GH-4006)
https://github.com/python/cpython/commit/5a66c8a64d180b5f3c80307924adaec53cc8faa3


--
nosy: +inada.naoki

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Change by Antoine Pitrou :


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

[issue31960] Protection against using a Future with another loop only works with await

[Yury Selivanov]

Yury Selivanov  added the comment:

I guess you can set Resolution to "postponed", Stage to "Resolved".

--

___
Python tracker 

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

[issue31970] asyncio debug mode is very slow

[Antoine Pitrou]

Change by Antoine Pitrou :


--
pull_requests: +4280

___
Python tracker 

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

[issue31970] asyncio debug mode is very slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 921e9432a1461bbf312c9c6dcc2b916be6c05fa0 by Antoine Pitrou in 
branch 'master':
bpo-31970: Reduce performance overhead of asyncio debug mode. (#4314)
https://github.com/python/cpython/commit/921e9432a1461bbf312c9c6dcc2b916be6c05fa0


--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The documentation has been fixed.  Should we close this now?  Ideally I'd 
rather have asyncio warn me in such situations, but I feel this won't be doable.

--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 518c6b97868d9c665475a40567b0aa417afad607 by Antoine Pitrou (Miss 
Islington (bot)) in branch '3.6':
bpo-31960: Fix asyncio.Future documentation for thread (un)safety. (GH-4319) 
(#4320)
https://github.com/python/cpython/commit/518c6b97868d9c665475a40567b0aa417afad607


--

___
Python tracker 

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

[issue31965] Incorrect documentation for multiprocessing.connection.{Client, Listener}

[Antoine Pitrou]

Change by Antoine Pitrou :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

___
Python tracker 

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

[issue31965] Incorrect documentation for multiprocessing.connection.{Client, Listener}

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset d9c61c2a2662761dc89e0be14ceb7ea57531c836 by Antoine Pitrou (Miss 
Islington (bot)) in branch '3.6':
bpo-31965: fix doc for multiprocessing.connection.Client and Listener (GH-4304) 
(#4321)
https://github.com/python/cpython/commit/d9c61c2a2662761dc89e0be14ceb7ea57531c836


--

___
Python tracker 

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

[issue31965] Incorrect documentation for multiprocessing.connection.{Client, Listener}

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Maybe the solution is to fix Tornado?

That's a possibility.  I have to convince Ben Darnell that it deserves fixing 
:-)

Another possibility is to use the asyncio concurrency primitives on Python 3, 
though that slightly complicates things, especially as the various coroutines 
there don't take a timeout parameter.

--
stage: patch review -> 

___
Python tracker 

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

[issue31965] Incorrect documentation for multiprocessing.connection.{Client, Listener}

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 1e5d54cfa031f1de9ee2d2e968e0551b6e2397b7 by Antoine Pitrou (Jelle 
Zijlstra) in branch 'master':
bpo-31965: fix doc for multiprocessing.connection.Client and Listener (#4304)
https://github.com/python/cpython/commit/1e5d54cfa031f1de9ee2d2e968e0551b6e2397b7


--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4278
stage:  -> patch review

___
Python tracker 

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

Re: What happens to module's variables after a "from module import" ?

[ast]

"Paul Moore"  a écrit dans le message de 
news:mailman.53.1510069830.2819.python-l...@python.org...

On 7 November 2017 at 15:39, ast  wrote:




It's in the "tmp" module, where you defined it. But because you didn't
ask for a reference to it in your import statement, it's not
accessible to you[1].
Do

   import tmp
   print(tmp.a)

and you can see it.

Paul

[1] Technically you can find it via the globals of the function test,
as test.__globals__['a'], but if you understand how that works, you
wouldn't have been asking the question in the first place :-)


Clear, ty 


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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 22b1128559bdeb96907da5840960691bb050d11a by Antoine Pitrou in 
branch 'master':
bpo-31960: Fix asyncio.Future documentation for thread (un)safety. (#4319)
https://github.com/python/cpython/commit/22b1128559bdeb96907da5840960691bb050d11a


--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Yury Selivanov]

Yury Selivanov  added the comment:

> Just try the snippet :-) If you want to see it finish in a finite time, move 
> the future instantiation inside the coroutine.

Yeah, I see the problem.  OTOH your proposed change to lazily attach a loop to 
the future isn't fully backwards compatible.  It would be a nightmare to find a 
bug in a large codebase caused by this change in Future behaviour.  So I'm -1 
on this idea, that ship has sailed.

> Unfortunately that's not possible in our case.  Short version: we are using 
> Tornado which creates a asyncio Future eagerly, see 
> https://github.com/tornadoweb/tornado/blob/master/tornado/locks.py#L199

Maybe the solution is to fix Tornado?

--

___
Python tracker 

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

Re: What happens to module's variables after a "from module import" ?

[Peter Otten]

ast wrote:

> Hello
> 
> Here is my module tmp.py:
> 
> a=0
> 
> def test():
> global a
> print(a)
> a+=1
> 
> If I import function "test" from module "tmp" with:
> 
 from tmp import test
> 
> it works
> 
 test()
> 0
 test()
> 1
> 
> But where variable "a" is located ? I can't find it anywhere

The function keeps a reference to the global namespace of the tmp module.

>>> from tmp import test
>>> test.__globals__["a"]
0
>>> test()
0
>>> test.__globals__["a"]
1

The module is cached; thus a subsequent import gives the same function and 
of course accesses the same global namespace:

>>> from tmp import test as test2
>>> test is test2
True
>>> test2()
1

When you remove the module from the cache (usually a bad idea, done here for 
demonstration purposes) you will get a new function and a new global 
namespace:

>>> import sys
>>> del sys.modules["tmp"]
>>> from tmp import test as test3
>>> test is test3
False
>>> test()
2
>>> test3()
0


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

Re: Incomplete description using sqlite3

[Sibylle Koczian]

Am 06.11.2017 um 23:40 schrieb Skip Montanaro:

I'm using sqlite3 (2.6.0, SQLite version 3.13.0, Python 2.7.13) and
was hoping to introspect the types of a table using the cursor's
description attribute. PEP 249 states: "The first two items (name and
type_code) are mandatory..." I tried this query:

conn = sqlite3("/some/existing/database")
curs = conn.cursor()
curs.execute("select * from mytable limit 1")
curs.fetchall()

Looking at curs.description, I see that it contained a seven-element
tuple for each column, but only the first element (name) was non-None.
Even the type_code field (required, according to the PEP) was None. I
tried the same trick using pyodbc talking to SQL Server (select top(1)
* from mytable). It returned more useful information.

Did I go about things wrong with SQLite, or is the sqlite3 module (or
SQLite database underlying it) not capable enough?

Thx,

Skip



I'd suspect the explanation is here:
https://sqlite.org/datatype3.html

HTH
Sibylle

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

Re: What happens to module's variables after a "from module import" ?

[Paul Moore]

On 7 November 2017 at 15:39, ast  wrote:
> Hello
>
> Here is my module tmp.py:
>
> a=0
>
> def test():
>global a
>print(a)
>a+=1
>
> If I import function "test" from module "tmp" with:
>
 from tmp import test
>
>
> it works
>
 test()
>
> 0

 test()
>
> 1
>
> But where variable "a" is located ? I can't find it anywhere

It's in the "tmp" module, where you defined it. But because you didn't
ask for a reference to it in your import statement, it's not
accessible to you[1].
Do

import tmp
print(tmp.a)

and you can see it.

Paul

[1] Technically you can find it via the globals of the function test,
as test.__globals__['a'], but if you understand how that works, you
wouldn't have been asking the question in the first place :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> So imagine a Future `fut` is completed. And we call `fut.add_done_callback()` 
> in different contexts with different active event loops.  With your 
> suggestion we'll schedule our callbacks in different loops.

I'm wondering: does this situation occur in practice?  Since Future isn't 
threadsafe, is there really a point in using it from several loops at once?

> Ideally you should use `loop.create_future()` when you can (and in libraries 
> you usually can do that) to always make it explicit which loop your Future is 
> attached to.

Unfortunately that's not possible in our case.  Short version: we are using 
Tornado which creates a asyncio Future eagerly, see 
https://github.com/tornadoweb/tornado/blob/master/tornado/locks.py#L199

--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Yury Selivanov]

Yury Selivanov  added the comment:

> My underlying question is why the Future has to set its loop in its 
> constructor, instead of simply using get_event_loop() inside 
> _schedule_callbacks().  This would always work.

So imagine a Future `fut` is completed. And we call `fut.add_done_callback()` 
in different contexts with different active event loops.  With your suggestion 
we'll schedule our callbacks in different loops.

Ideally you should use `loop.create_future()` when you can (and in libraries 
you usually can do that) to always make it explicit which loop your Future is 
attached to.

--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The call_soon / call_soon_threadsafe distinction is not relevant to the problem 
I posted.  The problem is that the Future is registered with the event loop for 
the thread it was created in, even though it is only ever used in another 
thread (with another event loop).

Just try the snippet :-) If you want to see it finish in a finite time, move 
the future instantiation inside the coroutine.

--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Yury Selivanov]

Yury Selivanov  added the comment:

>> I think we should update `Future._schedule_callbacks` to check if the loop 
>> is in debug mode.

> Unfortunately this is not sufficient for the snippet I posted.  The loop's 
> thread_id is only set when the loop runs, but the main loop in that example 
> never runs.

If the loop isn't running, call_soon works just fine from any thread.  

call_soon_threadsafe is different from call_soon when the loop *is* running.  
When it's running and blocked on IO, call_soon_threadsafe will make sure that 
the loop will be woken up.

Currently, _schedule_callbacks() calls loop.call_soon(), which already calls 
loop._check_thread().  So it looks like we don't need to change anything after 
all, right?

--
stage: patch review -> 

___
Python tracker 

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

What happens to module's variables after a "from module import" ?

[ast]

Hello

Here is my module tmp.py:

a=0

def test():
   global a
   print(a)
   a+=1

If I import function "test" from module "tmp" with:


from tmp import test


it works


test()

0

test()

1

But where variable "a" is located ? I can't find it anywhere


Regards






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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Change by Antoine Pitrou :


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

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:

My underlying question is why the Future has to set its loop in its 
constructor, instead of simply using get_event_loop() inside 
_schedule_callbacks().  This would always work.

--

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -haypo

___
Python tracker 

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

[issue31960] Protection against using a Future with another loop only works with await

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> My opinion on this: update documentation for all Python versions to reflect 
> that Future uses call_soon.

Agreed.

> I think we should update `Future._schedule_callbacks` to check if the loop is 
> in debug mode.

Unfortunately this is not sufficient for the snippet I posted.  The loop's 
thread_id is only set when the loop runs, but the main loop in that example 
never runs.

--

___
Python tracker 

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

[issue31971] idle_test: failures on x86 Windows7 3.x

[STINNER Victor]

New submission from STINNER Victor :

http://buildbot.python.org/all/#/builders/58/builds/122

==
ERROR: tearDownClass (idlelib.idle_test.test_configdialog.KeysPageTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\idlelib\idle_test\test_configdialog.py",
 line 701, in tearDownClass
del page.set_keys_type, page.load_keys_list
AttributeError: set_keys_type
==
FAIL: test_set_keys_type (idlelib.idle_test.test_configdialog.KeysPageTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\idlelib\idle_test\test_configdialog.py",
 line 859, in test_set_keys_type
eq(d.custom_keyset_on.state(), ('selected',))
AssertionError: Tuples differ: ('selected', 'hover') != ('selected',)
First tuple contains 1 additional elements.
First extra element 1:
'hover'
- ('selected', 'hover')
? 
+ ('selected',)

--
components: Tests
messages: 305763
nosy: haypo, terry.reedy
priority: normal
severity: normal
status: open
title: idle_test: failures on x86 Windows7 3.x
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

Re: Easiest way to access C module in Python

[bartc]

On 07/11/2017 14:33, Tim Golden wrote:

On 07/11/2017 14:20, bartc wrote:


You've lost me. I had to look up pyPI and it's something to do with a 
Package Index. But I don't know how that relates to installing Cython.


Can I just step in now with my Moderator hat on and ask: please avoid a 
lengthy "educate Bart C about Python" thread. If anyone wants to take it 
up with him in private, that's up to you. But please leave it off the 
list / newsgroup.


Well, that's not going to work because my email is not valid. But I've 
already said I'm not interested, and this is anyway getting a long way 
from what the OP is trying to do. I've stated that ctypes is my 
preferred approach for that.


However I doubt I'm the only one having trouble with these peripheral 
aspects, and a mention of such problems can help others, even if it's 
for reassurance that the problems are not their fault!


(This of course doesn't apply to the expert contributors here.)

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

[issue31966] [EASY C][Windows] print('hello\n', end='', flush=True) raises OSError when ran with py -u

[STINNER Victor]

STINNER Victor  added the comment:

The _io__WindowsConsoleIO_write_impl() function should be fixed to not call 
MultiByteToWideChar() but use 0 if the input string is zero. Ok, it makes sense.

In that case, I agree to call it a simple issue ;-)

--
title: print('hello\n', end='', flush=True) raises OSError when ran with py -u 
-> [EASY C][Windows] print('hello\n', end='', flush=True) raises OSError when 
ran with py -u

___
Python tracker 

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

Re: Easiest way to access C module in Python

[Tim Golden]

On 07/11/2017 14:20, bartc wrote:

On 07/11/2017 13:30, Thomas Jollans wrote:

On 2017-11-07 12:53, bartc wrote:

Having
said that, I located pip.exe, trying typing 'pip install cffi' and it
seemed to be doing something but then failed with a bunch of errors.)


So you're missing out on all of PyPI? That's tragic. You should really
try to fix that. I'm sure people on this list will be happy to help if
you start a new thread with some details of what is happening on your
system.


You've lost me. I had to look up pyPI and it's something to do with a 
Package Index. But I don't know how that relates to installing Cython.


Can I just step in now with my Moderator hat on and ask: please avoid a 
lengthy "educate Bart C about Python" thread. If anyone wants to take it 
up with him in private, that's up to you. But please leave it off the 
list / newsgroup.


Thanks

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

[issue31960] Protection against using a Future with another loop only works with await

[Yury Selivanov]

Yury Selivanov  added the comment:

> On the other hand, the Future implementation is entirely not thread-safe 
> (btw, the constructor optimistically claims the done callbacks are scheduled 
> using call_soon_threadsafe(), but the implementation actually calls 
> call_soon()).

This is weird.  PEP 3156 specifies that Future uses call_soon.  The 
implementation uses call_soon.  And it actually makes sense to use call_soon 
for Futures.  

Situations when Future.cancel() or Future.set_result() is called from a 
different thread are extremely rare, so we want to avoid the overhead of using 
call_soon_threadsafe().  Moreover, I bet there are many other cases where 
Future implementation is not threadsafe.

If one absolutely needs to call Future.set_result() from a different thread, 
they can always do `loop.call_soon_threadsafe(fut.set_result, ...)`.

My opinion on this: update documentation for all Python versions to reflect 
that Future uses call_soon.

> Do you think it would be fine for Future._schedule_callbacks() to check the 
> event loop is the current one, or do you think it would impact performance 
> too much (or perhaps it is simply not desirable)?

I think we should update `Future._schedule_callbacks` to check if the loop is 
in debug mode.  If it is call `loop._check_thread()`, which will raise a 
RuntimeError if the current thread is different from the one that the loop 
belongs to.  

This will have no detectable overhead, but will ease debugging of edge cases 
like writing multithreaded asyncio applications.

--

___
Python tracker 

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

Re: Easiest way to access C module in Python

[bartc]

On 07/11/2017 13:30, Thomas Jollans wrote:

On 2017-11-07 12:53, bartc wrote:

Having
said that, I located pip.exe, trying typing 'pip install cffi' and it
seemed to be doing something but then failed with a bunch of errors.)


So you're missing out on all of PyPI? That's tragic. You should really
try to fix that. I'm sure people on this list will be happy to help if
you start a new thread with some details of what is happening on your
system.


You've lost me. I had to look up pyPI and it's something to do with a 
Package Index. But I don't know how that relates to installing Cython.


The problem with pip was in Py3.4. I also have Py3.6, and that didn't 
have pip at all. Or it is something that itself needs to be installed 
first? Or is pyPI a new thing that replaces it?


I'm not a serious Python user so it's not worth the effort of going 
around in circles trying to get these things working. I remember how 
difficult it was to get Numpy going a couple of years back.


If it's already built-in, then fine, but if not, forget it. But for me 
it doesn't matter.


--
bartc



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

[issue31955] distutils C compiler: set_executables() incorrectly parse values with spaces

[Dee Mee]

Dee Mee  added the comment:

I agree, that this fix is necessary only for Python 2. Submitted new PR 4316

--
versions:  -Python 3.6, Python 3.7

___
Python tracker 

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