[issue34366] _uuid module fails to compile on FreeBSD when libuuid is installed

[Michał Górny]

Change by Michał Górny :


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

___
Python tracker 

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

[issue34360] urllib.parse doesn't fail with multiple unmatching square brackets

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue32638] distutils test errors with AIX and xlc

[Michael Felt]

Michael Felt  added the comment:

this can be closed. Discussion, if any, at 
https://github.com/python/cpython/pull/8709 or issue11191

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

[issue34347] AIX: test_utf8_mode.test_cmd_line fails

[Michael Felt]

Michael Felt  added the comment:

Starting this discussion again. Please take time to read. I have spent hours 
trying to understand what is failing. Please spend a few minutes reading.

Sadly, there is a lot of text - but I do not know what I could leave out 
without damaging the process of discovery.

The failing result is:

self.assertEqual(args, ascii(expected), out)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != 
"['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\udcc3\udca9\udce2\udc82\udcac']
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

The test code is:
  +207  @unittest.skipIf(MS_WINDOWS, 'test specific to Unix')
  +208  def test_cmd_line(self):
  +209  arg = 'h\xe9\u20ac'.encode('utf-8')
  +210  arg_utf8 = arg.decode('utf-8')
  +211  arg_ascii = arg.decode('ascii', 'surrogateescape')
  +212  code = 'import locale, sys; print("%s:%s" % 
(locale.getpreferredencoding(), ascii(sys.argv[1:])))'
  +213
  +214  def check(utf8_opt, expected, **kw):
  +215  out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
  +216  args = out.partition(':')[2].rstrip()
  +217  self.assertEqual(args, ascii(expected), out)
  +218
  +219  check('utf8', [arg_utf8])
  +220  if sys.platform == 'darwin' or support.is_android:
  +221  c_arg = arg_utf8
  +222  else:
  +223  c_arg = arg_ascii
  +224  check('utf8=0', [c_arg], LC_ALL='C')

Question 1: why is windows excluded? Because it does not use UTF-8 as it's 
default (it's default is CP1252)

Question 2: It seems that what the test is 'checking' is that 
object.encode('utf-8') gets decoded by ascii() based on the utf8_mode set.

 +215  out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)

rewrites (less indent) as:
 +215  out = self.get_output('-X', utf8_opt, '-c', code, 
'h\xe9\u20ac'.encode('utf-8'), **kw)

or
out = self.get_output('-X', utf8_opt, '-c', code, b'h\xc3\xa9\xe2\x82\xac', 
**kw)

Finally, in  Lib/test/support/script_helper.py we have
  +127  print("\n", cmd_line) # debug info, ignore
  +128  proc = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
  +129   stdout=subprocess.PIPE, stderr=subprocess.PIPE,
  +130   env=env, cwd=cwd)

Which gives:

 ['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8', 
'-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), 
ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']

Above - utf8=1 - is successful

 ['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8=0', 
'-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), 
ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']

Here: utf8=0 fails. The arg to the CLI is equal in both cases.
FAIL

## Goiing back to check() and what does it have:
## Add some debug. The first line is the 'raw' expected,
## the second line is ascii(decoded)
## the final is the value extracted from get_output

  +214  def check(utf8_opt, expected, **kw):
  +215  out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
  +216  args = out.partition(':')[2].rstrip()
  +217  print("")
  +218  print("%s: expected\n%s:ascii(expected)\n%s:out" % 
(expected, ascii(expected), out))
  +219  self.assertEqual(args, ascii(expected), out)

For: utf8 mode true, it works:
['h▒\u20ac']: expected
['h\xe9\u20ac']:ascii(expected)
UTF-8:['h\xe9\u20ac']:out

  +221  check('utf8', [arg_utf8])

But not for utf8=0
  +226  check('utf8=0', [c_arg], LC_ALL='C')
 # note, different values for LC_ALL='C' have been tried
['h\udcc3\udca9\udce2\udc82\udcac']: expected
['h\udcc3\udca9\udce2\udc82\udcac']:ascii(expected)
ISO8859-1:['h\xc3\xa9\xe2\x82\xac']:out

## re: expected and ascii(expected)
When utf8=1 expected and ascii(expected) differ. "arg" looks different from 
both - but after processing by get_object() expected and out match.

When utf8=0 there is no difference is "arg1" passed to "code".
However, whith check - the values for both expected and ascii(expected) are 
identical. And, sadly, the value coming back via get_output looks nothing like 
'expected'.

In short, when utf8=1 ascii(b'h\xc3\xa9\xe2\x82\xac') becomes ['h\xe9\u20ac' 
which is what is desired. But when utf8=0 ascii(b'h\xc3\xa9\xe2\x82\xac') is 
b'h\xc3\xa9\xe2\x82\xac' not 'h\udcc3\udca9\udce2\udc82\udcac'

Finally, when I run the command from the command line (after rewrites)

What passes:
./python '-X' 'faulthandler' '-X' 'utf8=1' '-c' 'import locale, sys; 
print("%s:%s" % (locale.getpreferredencoding(), ascii(
sys.argv[1:])))' b'h\xc3\xa9\xe2\x82\xac'
UTF-8:['bh\\xc3\\xa9\\xe2\\x82\\xac']

encoding is UTF-8, but the result of ascii(argv[1]) is the same as argv[1]

./python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; 
print("%s:%s" % (lo

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

The problem with this solution is that it may brea (relatively common) use case 
of tuple valued fields, e.g.:

>>> tuple(*[x for x in a])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: tuple expected at most 1 arguments, got 2

Essentially, named tuples are all subclasses of `tuple` but they override 
__new__ in an incompatible way.

--

___
Python tracker 

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

[issue27494] 2to3 parser failure caused by a comma after a generator expression

[Łukasz Langa]

Łukasz Langa  added the comment:

This is one of those issues where it's clear that the parser and 2to3 should be 
separate.

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue34212] Cygwin link failure with builtin modules since issue30860

[Erik Bray]

Change by Erik Bray :


--
pull_requests: +8199

___
Python tracker 

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

[issue34212] Cygwin link failure with builtin modules since issue30860

[Erik Bray]

Erik Bray  added the comment:

I added a new PR modifying makesetup and adding a new variable to 
Makefile.pre.in, PY_BUILTIN_MODULE_CFLAGS, explicitly for building built-in 
modules.

I think this, or some version of it, is a cleaner solution than my previous 
brute-force approach.

--

___
Python tracker 

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

[issue34367] AsyncResult.get() only notifies one thread

[Alexander Tsvetkov]

New submission from Alexander Tsvetkov :

If more than one thread is waiting for the multiprocessing.pool.AsyncResult 
(aka ApplyResult) returned from apply_async, only one thread will be notified 
once the result arrives.

It happens because AsyncResult._set calls notify upon the result arrival, not 
notify_all.

threading.Event used in Python 3 uses notify_all.

Reproduction script is attached.
Expected outcome:
1
1
is printed to STDOUT.

Observed outcome:
The script hangs.

--
components: Library (Lib)
files: async_result_demo.py
messages: 323323
nosy: AlexWithBeard
priority: normal
severity: normal
status: open
title: AsyncResult.get() only notifies one thread
versions: Python 2.7
Added file: https://bugs.python.org/file47736/async_result_demo.py

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Eric Snow]

Eric Snow  added the comment:

FWIW, the C implementation of Task.__init__ is not exactly equivalent to the 
Python implementation (nor to both the C and Python implementation of 
Task.set_name).  In the C impl of Task.__init__ the provided name is used as-is 
if it's an instance of str:

   (_asyncio_Task___init___impl() in Modules/_asynciomodule.c)

   if (name == Py_None) {
   name = PyUnicode_FromFormat("Task-%" PRIu64, ++task_name_counter);
   } else if (!PyUnicode_Check(name)) {
   name = PyObject_Str(name);
   } else {
   Py_INCREF(name);
   }

One of the following should happen, right?

1. fix the Python implementation of Task.__init__() and both impl of 
Task.set_name()
2. change the check to PyUnicode_CheckExact()
3. remove the special-case (i.e. change the C impl to match the Python impl)

p.s. Sorry I did not notice this before it got committed. :/

--
nosy: +eric.snow

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Yury Selivanov  added the comment:

> 2. change the check to PyUnicode_CheckExact()

I'd be OK with this, but why is this important?

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Yury Selivanov  added the comment:

As a side note, Alex, what do you think about appending coroutine's name to 
Task's name if the latter is autogenerated?

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

I also couldn't figure out yet why PyUnicode_Check() was necessary in the first 
place. Doesn't PyObject_Str() just increment the refcount if the argument is 
already a string?

Eric, please explain why these changes should be done.

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

Yury, I have no objections. Furthermore, it would be nice to expose the 
coroutine object publicly, like curio and trio do. It would make life simpler 
for me in some cases.

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Yury Selivanov  added the comment:

> I also couldn't figure out yet why PyUnicode_Check() was necessary in the 
> first place. Doesn't PyObject_Str() just increment the refcount if the 
> argument is already a string?

`str()` returns its argument if it's exactly a `builtins.str` instance.  If 
it's a subclass of str, it will construct a `builtins.str` out of it.

>>> class mystr(str):
... pass
>>> a = mystr('aaa')
>>> str(a) is a
False

So Eric is right, there's a small discrepancy between Python and C version.

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

Ok, I understand. But is the conversion a bad thing then?

--

___
Python tracker 

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

[issue34324] Doc README wrong directory name for venv

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:


New changeset 599bfa18f8ebcb23af300b6855934048c3c64e7d by Mariatta (Stéphane 
Wirtel) in branch 'master':
bpo-34324: Doc README wrong directory name for venv (GH-8650)
https://github.com/python/cpython/commit/599bfa18f8ebcb23af300b6855934048c3c64e7d


--
nosy: +Mariatta

___
Python tracker 

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

[issue34324] Doc README wrong directory name for venv

[miss-islington]

Change by miss-islington :


--
pull_requests: +8200

___
Python tracker 

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

[issue34324] Doc README wrong directory name for venv

[miss-islington]

Change by miss-islington :


--
pull_requests: +8201

___
Python tracker 

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

[issue34324] Doc README wrong directory name for venv

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

Thanks!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue34324] Doc README wrong directory name for venv

[miss-islington]

miss-islington  added the comment:


New changeset fe8f90aa3ca3f277cac634cdb96b829039225c6b by Miss Islington (bot) 
in branch '3.7':
bpo-34324: Doc README wrong directory name for venv (GH-8650)
https://github.com/python/cpython/commit/fe8f90aa3ca3f277cac634cdb96b829039225c6b


--
nosy: +miss-islington

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Yury Selivanov  added the comment:

> Ok, I understand. But is the conversion a bad thing then?

It's not a bad thing, it's just that we don't do it in C Task and we do it in 
pure Python Task.  Eric wants us to synchronize them so that in a very unlikely 
scenario where someone uses subclasses of str for names they will have exact 
same behaviour under both Tasks implementations.

I'd say let's just fix the C version to use PyUnicode_CheckExact.  Even though 
it's highly unlikely somebody ever hits this, there's no reason to keep Python 
and C implementations even slightly out of sync w.r.t. behaviour.

--

___
Python tracker 

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

[issue34324] Doc README wrong directory name for venv

[miss-islington]

miss-islington  added the comment:


New changeset 0ee2a29585e3c17e38eb6e6a2515405e40be22b5 by Miss Islington (bot) 
in branch '3.6':
bpo-34324: Doc README wrong directory name for venv (GH-8650)
https://github.com/python/cpython/commit/0ee2a29585e3c17e38eb6e6a2515405e40be22b5


--

___
Python tracker 

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

[issue34362] User-created types with wrong __new__ can be instantiated

[Eric Snow]

Eric Snow  added the comment:

I'm not sure that this is a duplicate of #5322.  That one's about a warning 
when arguments are passed to object.__new__().  Yours is about using an 
incompatible __new__ when creating a new class in Python.  I agree that 
behavior you're seeing is unexpected and should probably be fixed.

Let's look at the situation a little more closely.  Here's what I understood 
you reported:

>>> class X:
...   __new__ = tuple.__new__
...
>>> x1 = X()  # This does not fail!

However, that is a little misleading because you might think it is calling 
tuple.__new__().  It isn't.  Apparently type.__call__() is invoking 
object.__new__() instead of X.__new__():

>>> x2 = X([1, 2])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object() takes no parameters
>>> object.__new__(X, [1, 2])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object() takes no parameters

If I had a little more time I'd look into the relevant code to see what's going 
on.  In the meantime, let's see if we can find the edges of this problem.

We can verify that X.__new__ is still set to tuple.__new__:

>>> X.__new__ is object.__new__
False
>>> X.__new__ is tuple.__new__
True
>>> X.__new__(X)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: tuple.__new__(X): X is not a subtype of tuple
>>> X.__new__(X, [1, 2])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: tuple.__new__(X): X is not a subtype of tuple
>>> X.__new__(tuple)
()
>>> X.__new__(tuple, [1, 2])
(1, 2)

If we explicitly defer to tuple.__new__() then we get an error that matches our 
expectations better:

>>> class Y:
...   def __new__(cls, *args, **kwargs):
... return tuple.__new__(cls, *args, **kwargs)
...
>>> y = Y()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __new__
TypeError: tuple.__new__(Y): Y is not a subtype of tuple

This reinforces the conclusion that tuple.__call__() is doing something funny 
here.  We can take that conclusion further by seeing that the unexpected 
behavior is not specific to using tuple.__new__:

>>> class Z:
...   __new__ = int.__new__
...
>>> z1 = Z()
>>> z2 = Z(42)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object() takes no parameters
>>> Z.__new__(Z)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: int.__new__(Z): Z is not a subtype of int

--
nosy: +eric.snow

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

> It's not a bad thing, it's just that we don't do it in C Task and we do it in 
> pure Python Task.  Eric wants us to synchronize them so that in a very 
> unlikely scenario where someone uses subclasses of str for names they will 
> have exact same behaviour under both Tasks implementations.

Should a new issue be created for this so I can make a PR against it?

--

___
Python tracker 

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

[issue34367] AsyncResult.get() only notifies one thread

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Yury Selivanov  added the comment:

Let's just reuse this issue, it's just a small fix.

--
resolution: fixed -> 

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

Which way do we want to change this? Do we want to convert to pure strings or 
retain the original object? In the latter case both the C and Python 
implementations (including set_name()) have to be changed.

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Eric Snow]

Eric Snow  added the comment:

I'm not too invested in any changes happening at this point, actually. :)  
Mostly I happened to be reading through the commit and noticed the 
inconsistency.  If I had reviewed the PR then I would have asked that it be 
fixed.  So I figured I'd mention it.

FWIW, I don't expect it would cause any problems.  It could result in a 
different (between the two implementations) Task repr if the name's type (a str 
subclass) implements __repr__.  There's also the possibility of side-effects 
(from the implementation of the name's type).  Neither is a big deal 
(especially the latter since it's *not* a common use case).  On the other had, 
the matter is made moot by using PyUnicode_CheckExact(). :)

--
resolution:  -> fixed

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

> On the other had, the matter is made moot by using PyUnicode_CheckExact()

Then, in order to keep the pure Python implementation in sync, we'd have to 
change it to something like this:

if name is None:
   self._name = f'Task-{_task_name_counter()}'
elif isinstance(name, str):
   self._name = name
else:
   self._name = str(name)

I don't know about you, but it looks pretty awkward to me.

--
resolution: fixed -> 

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

> Please just change PyUnicode_Check to PyUnicode_CheckExact in C Task.__init__ 
> and use the same if check in C Task.set_name.

I'll do that if you say so, but I'm just saying that the C and Python 
implementations will still remain different in semantics then.

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Yury Selivanov  added the comment:

Please just change PyUnicode_Check to PyUnicode_CheckExact in C Task.__init__ 
and use the same if check in C Task.set_name.

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Yury Selivanov  added the comment:

> I'll do that if you say so, but I'm just saying that the C and Python 
> implementations will still remain different in semantics then.

Probably I'm missing something here. How would they be different?

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Alex Grönholm  added the comment:

> 
I'll do that if you say so, but I'm just saying that the C and Python 
implementations will still remain different in semantics then.

Never mind, that was a brain fart. I keep ignoring the "!" in my mind.

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Alex Grönholm]

Change by Alex Grönholm :


--
pull_requests: +8202

___
Python tracker 

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

[issue32102] Add "capture_output=True" option to subprocess.run

[Andriy Maletsky]

Change by Andriy Maletsky :


--
pull_requests: +8204

___
Python tracker 

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

[issue34362] User-created types with wrong __new__ can be instantiated

[ppperry]

ppperry  added the comment:

issue5322, despite its confusing title, mentions this exact bug in one of the 
comments below. 

It looks like there is one bug in the logic for assigning `__new__`, which 
causes `__new__` and `tp_new` to point to different things, confusing the 
error-handling logic in `object.__new__` as well as causing creation of a type 
by calling it to work in cases where direct calls to __new__ fail.

There's no one bug report about that, however issue5322, issue25731 and some 
cases of issue34284 are all symptoms of the same root issue.

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

I've tried to check the source code of IDLE in search of chained comparisons 
without parenthesis (like the example I showed and the bug with the mouse 
wheel). I couldn't find something important.

Then I wrote in a file the following code:

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(200)]
text.insert(tkinter.END, ''.join(lines))

In both Python 3.6 and 3.7 with Tk 8.6.8 on macOS 10.13, click-and-drag on the 
upper half of the scrollbar slider has no effect (the slider sticks at the 
top), like in the bugs #1 and #3. I strongly suspect a tkinter problem, as the 
equivalent Tcl/Tk code functions well. Click-and-drag in the lower half of the 
slider functions (in my code and IDLE) for me. Can someone reproduce this?

--

___
Python tracker 

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

[issue34270] Add names to asyncio tasks

[Yury Selivanov]

Change by Yury Selivanov :


--
resolution:  -> fixed

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

Edit:

The code is:

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
 
def click_trace(event):
text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x, 
event.y, vbar.identify(event.x, event.y)))

vbar.bind('', click_trace)

root.mainloop()

Clicking at the top on the slider shows that the Scrollbar considers it as 
being on "through1" (in Tk the zone between the upper arrow and the "slider") 
and NOT on the "slider". Please, play with the script (python3 tktest.py) and 
see the results for yourselves.

--
Added file: https://bugs.python.org/file47737/tktest.py

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

And the result (video) of my script is attached to this post.

--
Added file: https://bugs.python.org/file47738/tkinter_scroll_issues.mov

___
Python tracker 

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

[issue32102] Add "capture_output=True" option to subprocess.run

[miss-islington]

Change by miss-islington :


--
pull_requests: +8205

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Vlad, can you test the current patch on PR 8678 on Mac?

--

___
Python tracker 

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

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

[Eric V. Smith]

Eric V. Smith  added the comment:

Maybe do both, then. Also, it's probably better for performance reasons (I 
know: premature optimization and all that ...):

@@ -1018,8 +1018,10 @@ def _asdict_inner(obj, dict_factory):
 value = _asdict_inner(getattr(obj, f.name), dict_factory)
 result.append((f.name, value))
 return dict_factory(result)
-elif isinstance(obj, (list, tuple)):
+elif type(obj) in (list, tuple):
 return type(obj)(_asdict_inner(v, dict_factory) for v in obj)
+elif isinstance(obj, (list, tuple)):
+return type(obj)(*[_asdict_inner(v, dict_factory) for v in obj])
 elif isinstance(obj, dict):
 return type(obj)((_asdict_inner(k, dict_factory), _asdict_inner(v, 
dict_factory))
   for k, v in obj.items())

I guess we could argue it's a bug in nametuples, but I don't see that getting 
us very far.

--

___
Python tracker 

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

[issue5322] object.__new__ argument calling autodetection faulty

[ppperry]

Change by ppperry :


--
nosy: +ppperry

___
Python tracker 

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

[issue34363] dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple

[Neil Girdhar]

Neil Girdhar  added the comment:

Sorry if I'm intruding here, but I really dislike that we are doing isinstance 
versus list, tuple, and dict.  And I dislike even more type(x) in (list, 
tuple).  I think the ideal thing to do would have been to check versus abstract 
base classes like isinstance(x, Sequence) and isinstance(x, Mapping).  The 
advantage to this is flexibility with user-defined types.

The problem seems to be that the abstract base classes don't promise anything 
about the constructor.  It seems like some Sequence types accept an Iterable 
(e.g. tuple), but others like NamedTuple want positional arguments.  I think 
this promise should be encoded in some way.

Maybe a third solution is to have NamedTuple special-cased out:

isinstance(x, Sequence) and not isinstance(x, NamedTuple)

If there are other Sequence types that do this (are there?) then an abstract 
base class could be created.

This solution has the benefit of playing the most nicely with user-defined 
classes.

--
nosy: +NeilGirdhar

___
Python tracker 

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

[issue34368] ftplib __init__ function can't handle 120 or 4xy reply when connect to the server

[H-ZeX]

Change by H-ZeX :


--
components: XML
nosy: H-ZeX
priority: normal
severity: normal
status: open
title: ftplib __init__ function can't handle 120 or 4xy reply when connect to 
the server
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue34368] ftplib __init__ function can't handle 120 or 4xy reply when connect to the server

[H-ZeX]

Change by H-ZeX :


--
components: +Library (Lib) -XML

___
Python tracker 

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

[issue34368] ftplib __init__ function can't handle 120 or 4xy reply when connect to the server

[H-ZeX]

New submission from H-ZeX :

in the __init__ function, call getresp,

however, the getresp don't handle the 120 reply which indicate the request 
should be delay or 421 reply

in the rfc 959 page 50, there are all reply that may return

Connection Establishment
120
220
220
421

--

___
Python tracker 

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

[issue34353] stat's python implementation of filemode (fallback) doesn't behave like the C implementation

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset b92c526ed5da474694f89e29d82565f2a654c29b by Benjamin Peterson 
(GPery) in branch 'master':
closes bpo-34353: Add sockets to stat.filemode fallback python implementation. 
(GH-8703)
https://github.com/python/cpython/commit/b92c526ed5da474694f89e29d82565f2a654c29b


--
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue32745] ctypes string pointer fields should accept embedded null characters

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +8206
stage: test needed -> patch review

___
Python tracker 

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

[issue32745] ctypes string pointer fields should accept embedded null characters

[Zackery Spytz]

Change by Zackery Spytz :


--
nosy: +ZackerySpytz

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Tal Einat]

Tal Einat  added the comment:


New changeset 077059e0f086cf8c8b7fb9d1f053e38ddc743f59 by Tal Einat in branch 
'master':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/077059e0f086cf8c8b7fb9d1f053e38ddc743f59


--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[miss-islington]

Change by miss-islington :


--
pull_requests: +8207

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[miss-islington]

Change by miss-islington :


--
pull_requests: +8208

___
Python tracker 

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

[issue34369] kqueue.control() documentation and implementation mismatch

[Toshio Kuratomi]

New submission from Toshio Kuratomi :

The current kqueue documentation specifies that timeout is a keyword argument 
but it can only be passed as a positional argument right now:

>>> import select
>>> ko = select.kqueue()
>>> ko.control([1], 0, timeout=10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: control() takes no keyword arguments
>>> help(ko.control)
Help on built-in function control:

control(...) method of select.kqueue instance
control(changelist, max_events[, timeout=None]) -> eventlist

Calls the kernel kevent function.
- changelist must be an iterable of kevent objects describing the changes
  to be made to the kernel's watch list or None.
- max_events lets you specify the maximum number of events that the
  kernel will return.
- timeout is the maximum time to wait in seconds, or else None,
  to wait forever. timeout accepts floats for smaller timeouts, too.

This may be related to https://bugs.python.org/issue3852 in which the 
max_events argument used to be documented as optional but the code made it 
mandatory.

--
components: Library (Lib)
messages: 323357
nosy: a.badger
priority: normal
severity: normal
status: open
title: kqueue.control() documentation and implementation mismatch
type: behavior
versions: Python 2.7, Python 3.7

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[Vlad Tudorache]

Vlad Tudorache  added the comment:

The scroll works. Many thanks, I thought the callback should have been 
rewritten, too. Should one open a different report for the clicks on the 
scrollbar ends, like in the script I put (independent of IDLE)?

--

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[miss-islington]

miss-islington  added the comment:


New changeset ea8835fb302447da82f265a5bc0f785353100271 by Miss Islington (bot) 
in branch '3.7':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/ea8835fb302447da82f265a5bc0f785353100271


--
nosy: +miss-islington

___
Python tracker 

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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

[miss-islington]

miss-islington  added the comment:


New changeset ca4badb5c0bedaa4ebcb33b9cad5f64750876750 by Miss Islington (bot) 
in branch '3.6':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/ca4badb5c0bedaa4ebcb33b9cad5f64750876750


--

___
Python tracker 

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