[issue18373] implement sys.get/setbyteswarningflag()

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue20269] Inconsistent behavior in pdb when pressing Ctrl-C

[Xavier de Gaye]

New submission from Xavier de Gaye:

With this script:
# START
def foo():
while 1:
pass

import pdb; pdb.set_trace()
foo()
# END

The following sequence of pdb commands aborts the script with a 
KeyboardInterrupt exception:
  next
  Ctrl-C
  continue

While the equivalent following sequence of commands allows the debugging 
session to continue as
expected:
  continue
  Ctrl-C
  continue

The first sequence of commands should behave as the second one.

A related problem is that the original SIGINT handler (named 
_previous_sigint_handler in the code)
is not restored when the program being debugged is stopped at a breakpoint that 
has been reached
after 'continue'.  _previous_sigint_handler is lost forever in this case when 
the user hits
'continue' after stopping at that breakpoint, which is quite common. This is 
annoying. For example,
trying to extend pdb with a 'detach' command that enables the debuggee to run 
freely after the
debugging session is terminated: the program cannot be killed anymore with 
SIGINT when the above
case occurs.

The attached patch attempts to fix these problems.
After applying the attached patch, the behavior of the 'next, Ctrl-C, continue' 
sequence of commands
is still wrong: this is another bug logged at issue 14788 with a patch and a 
test. Applying patch
14788 fixes this.

--
components: Library (Lib)
files: sigint.patch
keywords: patch
messages: 208151
nosy: georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: Inconsistent behavior in pdb when pressing Ctrl-C
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file33478/sigint.patch

___
Python tracker 

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

[issue20187] The Great Argument Clinic Conversion Derby Meta-Issue

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I want to warn against the converting of base objects (whose sources lie in 
Objects/). Their performance is critical and the converting can worsen it. 
Often they even don't use PyArg_ParseTuple due to performance reasons or 
because argument parsing is too special for PyArg_ParseTuple. I would suggest 
to postpone it until Argument Clinic will generate optimized parsing code.

The same is true for some modules. The performance of struct and operator is 
important. In any case these modules almost not use PyArg_ParseTuple and can be 
omitted.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue14455] plistlib unable to read json and binary plist files

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1a8149ba3000 by Ronald Oussoren in branch 'default':
Issue #14455: Fix some issues with plistlib
http://hg.python.org/cpython/rev/1a8149ba3000

--

___
Python tracker 

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

[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files

[Vajrasky Kok]

Vajrasky Kok added the comment:

Here is the patch for Python/marshal.c.

A couple of issues:
1. I can not have bytes as argument.

bytes: Py_buffer -> not possible

So I changed it to byte.

2. I can not give default value, marshal.version, to argument.

version: int(c_default="Py_MARSHAL_VERSION") = marshal.version -> not possible 
(unless I put "import marshal" in Tools/clinic/clinic.py).

So I gave it a raw value, 2.

version: int(c_default="Py_MARSHAL_VERSION") = 2

--
Added file: http://bugs.python.org/file33479/clinic_marshal.patch

___
Python tracker 

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

[issue14455] plistlib unable to read json and binary plist files

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue20270] urllib.parse doesn't work with empty port

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

According to RFC 3986 the port subcomponent is defined as zero or more decimal 
digits delimited from the host by a single colon. I.e. 'python.org:' is valid 
(but not normalized) form. Empty port is equivalent to absent port.

>>> import urllib.parse
>>> p = urllib.parse.urlparse('http://python.org:')
>>> p.hostname
'python.org'
>>> p.port  # should return None
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython-3.3/Lib/urllib/parse.py", line 156, in port
port = int(port, 10)
ValueError: invalid literal for int() with base 10: ''
>>> urllib.parse.splitport('python.org:')  # should return ('python.org', None)
('python.org:', None)
>>> urllib.parse.splitnport('python.org:')  # should return ('python.org', -1)
('python.org', None)
>>> urllib.parse.splitnport('python.org:', 80)  # should return ('python.org', 
>>> 80)
('python.org', None)

Proposed patch fixes this. It also adds tests for urllib.parse.splitport().

--
components: Library (Lib)
files: urllib_parse_empty_port.patch
keywords: patch
messages: 208155
nosy: orsenthil, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: urllib.parse doesn't work with empty port
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33480/urllib_parse_empty_port.patch

___
Python tracker 

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

[issue20271] urllib.parse.urlparse() accepts wrong URLs

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

>>> import urllib.parse
>>> p = urllib.parse.urlparse('http://[::1]spam:80')
>>> p
ParseResult(scheme='http', netloc='[::1]spam:80', path='', params='', query='', 
fragment='')
>>> p.hostname
'::1'
>>> p.port
80

'http://[::1]spam:80' is invalid URL, but urllib.parse.urlparse() accepts it 
and just ignore the spam part.

--
components: Library (Lib)
messages: 208156
nosy: orsenthil, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.parse.urlparse() accepts wrong URLs
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

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

[issue20271] urllib.parse.urlparse() accepts wrong URLs

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +urllib.parse doesn't work with empty port

___
Python tracker 

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

[issue18191] urllib2/urllib.parse.splitport does not handle IPv6 correctly

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Julien's patch is subject to bugs described in issue20270 and issue20271. As 
far as OpenStack Oslo library.

--
dependencies: +urllib.parse doesn't work with empty port, 
urllib.parse.urlparse() accepts wrong URLs
type:  -> behavior
versions: +Python 3.4 -Python 2.6

___
Python tracker 

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

[issue14455] plistlib unable to read json and binary plist files

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I see that plistlib incorrectly writes large ints from 2**63 to 2**64-1 as 
negative values.

>>> d = plistlib.dumps({'a': 18446744073709551615}, fmt=plistlib.FMT_BINARY)
>>> plistlib.loads(d)
{'a': -1}

My patch did this correct (as 128-bit integer), and as you can see the produced 
file is accepted by Apple's plutil.

--

___
Python tracker 

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

[issue14455] plistlib unable to read json and binary plist files

[Ronald Oussoren]

Ronald Oussoren added the comment:

However, I have no idea how to write that file using Apple's APIs. 

I'd prefer to either be compatible with Apple's API (current behavior), or just 
outright reject values that cannot be represented as a 64-bit signed integer.  

The file you generated happens to work, but as there is no way to create such 
as file using a public API there is little reason to expect that this will keep 
functioning in the future.  

The CFBinaryPlist code appears to be shared between support for binary plists 
and keyed archiving (more or less Cocoa's equivalent for pickle) and supports 
other values that cannot be put in plist files, such as sets.  The original 
patch supported sets in the binary plist reader and writer, I ripped that out 
because such objects cannot be serialised using Apple's plist APIs.

Keep in mind that this module is intended for interop with Apple's data format.

--

___
Python tracker 

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

[issue20009] Property should expose wrapped function.

[Nick Coghlan]

Nick Coghlan added the comment:

__wrapped__ is specifically for the case where the outer function is a 
relatively straightforward wrapper around the inner one (i.e. those cases where 
it would be appropriate to use functools.wraps or Graham Dumpleton's more 
sophisticated wrapt module).

More complex decorators and descriptors (like property) will define their own 
mechanism for accessing the internal details.

--
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14455] plistlib unable to read json and binary plist files

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> However, I have no idea how to write that file using Apple's APIs.

Look in CFBinaryPList.c. It have a code for creating 128-bit integers:

CFSInt128Struct val;
val.high = 0;
val.low = bigint;
*plist = CFNumberCreate(allocator, kCFNumberSInt128Type, &val);

And I suppose that you have at least one way to create such file -- just 
convert plist file in XML format to binary format.

> Keep in mind that this module is intended for interop with Apple's data
> format.

Apple's tool can read and write integers from 2**63 to 2**64-1.

Here is a patch against current sources.

--
Added file: http://bugs.python.org/file33481/plistlib_big_ints.patch

___
Python tracker 

___diff -r 1a8149ba3000 Doc/library/plistlib.rst
--- a/Doc/library/plistlib.rst  Wed Jan 15 11:32:35 2014 +0100
+++ b/Doc/library/plistlib.rst  Wed Jan 15 15:22:29 2014 +0200
@@ -107,13 +107,6 @@
An :exc:`OverflowError` will be raised for integer values that cannot
be represented in (binary) plist files.
 
-   .. warning::
-
-  For compatibility with Apple's libraries it is possible to write
-  an integer in the range from 2 ** 63 upto (and including) 2 ** 64
-  to binary plists, even though these will be read back as negative
-  values.
-
.. versionadded: 3.4
 
 
diff -r 1a8149ba3000 Lib/plistlib.py
--- a/Lib/plistlib.py   Wed Jan 15 11:32:35 2014 +0100
+++ b/Lib/plistlib.py   Wed Jan 15 15:22:29 2014 +0200
@@ -879,18 +879,19 @@
 try:
 self._fp.write(struct.pack('>Bq', 0x13, value))
 except struct.error:
-raise OverflowError(value)
+raise OverflowError(value) from None
 elif value < 1 << 8:
 self._fp.write(struct.pack('>BB', 0x10, value))
 elif value < 1 << 16:
 self._fp.write(struct.pack('>BH', 0x11, value))
 elif value < 1 << 32:
 self._fp.write(struct.pack('>BL', 0x12, value))
+elif value < 1 << 63:
+self._fp.write(struct.pack('>Bq', 0x13, value))
+elif value < 1 << 64:
+self._fp.write(b'\x14' + value.to_bytes(16, 'big', 
signed=True))
 else:
-try:
-self._fp.write(struct.pack('>BQ', 0x13, value))
-except struct.error:
-raise OverflowError(value)
+raise OverflowError(value)
 
 elif isinstance(value, float):
 self._fp.write(struct.pack('>Bd', 0x23, value))
diff -r 1a8149ba3000 Lib/test/test_plistlib.py
--- a/Lib/test/test_plistlib.py Wed Jan 15 11:32:35 2014 +0100
+++ b/Lib/test/test_plistlib.py Wed Jan 15 15:22:29 2014 +0200
@@ -152,7 +152,7 @@
 
 def test_int(self):
 for pl in [0, 2**8-1, 2**8, 2**16-1, 2**16, 2**32-1, 2**32,
-   2**63-1, 1, -2**63]:
+   2**63-1, 2**64-1, 1, -2**63]:
 for fmt in ALL_FORMATS:
 with self.subTest(pl=pl, fmt=fmt):
 data = plistlib.dumps(pl, fmt=fmt)
@@ -163,7 +163,7 @@
 self.assertEqual(data, data2)
 
 for fmt in ALL_FORMATS:
-for pl in (2 ** 64 + 1, 2 ** 127-1, -2**64, -2 ** 127):
+for pl in (2**64, 2**127-1, -2**63-1, -2**127):
 with self.subTest(pl=pl, fmt=fmt):
 self.assertRaises(OverflowError, plistlib.dumps,
   pl, fmt=fmt)
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14455] plistlib unable to read json and binary plist files

[Ronald Oussoren]

Ronald Oussoren added the comment:

kCFNumberSInt128Type is not public API, see the list of number types in 
.

I agree that CFBinaryPlist.c contains support for those, and for writing binary 
plists that contain sets, but you cannot create a 128 bit CFNumber object using 
a public API, and the public API for writing plists won't accept data 
structures containing sets.

--

___
Python tracker 

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

[issue14455] plistlib unable to read json and binary plist files

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

You have at least one way to create a 128 bit CFNumber. Read plist file (and 
you can create plist in XML format with big integers in any text editor).

In any case it is not good to produce incorrect plist for big integers. If you 
don't want to support integers over 2**63, just reject them.

--

___
Python tracker 

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

[issue14455] plistlib unable to read json and binary plist files

[Ronald Oussoren]

Ronald Oussoren added the comment:

Reopening because Cocoa behaves differently that I had noticed earlier...

The (Objective-C) code below serialises an NSDictionary with an unsigned long 
of value ULLONG_MAX and then reads it back. I had expected that restored value 
contained a negative number, but it actually reads back the correct value.

I'm going to do some more spelunking to find out what's going on here, and will 
adjust the plistlib code to fully represent all values of unsigned 64-bit 
integers (likely based on your code for supporting 128-bit integers)



Output (on a 64-bit system running OSX 10.9):

$ ./demo 
2014-01-15 15:34:18.196 demo[77580:507] input dictionary: {
key = 18446744073709551615;
}   value 18446744073709551615
2014-01-15 15:34:18.198 demo[77580:507] as binary plist: <62706c69 73743030 
d1010253 6b657914     080b0f00  
00010100  0300    20>
2014-01-15 15:34:18.198 demo[77580:507] Restored as {
key = 18446744073709551615;
}


Code:

/*
 * To use:
 *  $ cc -o demo demo.c -framework Cocoa
 *  $ ./demo
 */
#import 

int main(void)
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSNumber* value = [NSNumber numberWithUnsignedLongLong:ULLONG_MAX];

NSDictionary* dict = [NSDictionary dictionaryWithObjectsAndKeys:value, 
@"key", nil];
NSLog(@"input dictionary: %@   value %llu", dict, ULLONG_MAX);

NSData* serialized = [NSPropertyListSerialization
dataWithPropertyList:dict
  format: NSPropertyListBinaryFormat_v1_0
 options: 0
   error: nil];
NSLog(@"as binary plist: %@", serialized);

NSDictionary* restored = [NSPropertyListSerialization
propertyListWithData:serialized
 options:0
  format:nil
   error:nil];
NSLog(@"Restored as %@", restored);
return 0;
}

--
status: closed -> open

___
Python tracker 

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

[issue16251] pickle special methods are looked up on the instance rather than the type

[Barry A. Warsaw]

Changes 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

[issue14455] plistlib unable to read json and binary plist files

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> I'm going to do some more spelunking to find out what's going on here, and
> will adjust the plistlib code to fully represent all values of unsigned
> 64-bit integers (likely based on your code for supporting 128-bit integers)

My last patch supports only values up to 2**64-1.

Perhaps you will want to add new test case in 
Mac/Tools/plistlib_generate_testdata.py.

--

___
Python tracker 

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

[issue20261] Cannot pickle some objects that have a __getattr__()

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I'll go ahead and dupe this to 16251, but will note the __getnewargs__() 
regression in 3.4.

--
superseder:  -> pickle special methods are looked up on the instance rather 
than the type

___
Python tracker 

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

[issue16251] pickle special methods are looked up on the instance rather than the type

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I ran into this recently while porting nose to 3.4.  I duped 
http://bugs.python.org/issue20261 to this issue, but note that in 
http://bugs.python.org/issue20261#msg208109 I notice that the presence or 
absence of __getnewargs__() regresses the specific behavior in Python 3.4.

--

___
Python tracker 

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

[issue19804] test_uuid.TestUUID.test_find_mac() fails

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue14031] logging module cannot format str.format log messages

[Vinay Sajip]

Vinay Sajip added the comment:

Cookbook updated. See changesets 7c4f0c3dedaf and 0056aaf42bf7 for more 
information - docs.python.org should update within a day.

--

___
Python tracker 

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

[issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl

[Laurento Frittella]

Laurento Frittella added the comment:

I had the same problem using urllib2 and the following trick worked for me

import httplib
httplib.HTTPConnection._http_vsn = 10
httplib.HTTPConnection._http_vsn_str = 'HTTP/1.0'

Source: http://stackoverflow.com/a/20645845

--
nosy: +laurento.frittella

___
Python tracker 

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

[issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
type:  -> behavior
versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1, Python 3.2

___
Python tracker 

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

[issue20187] The Great Argument Clinic Conversion Derby Meta-Issue

[Larry Hastings]

Larry Hastings added the comment:

Can you give me an example of performance degradation due to Argument Clinic?  
What percentage slowdown is common?

--

___
Python tracker 

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

[issue20187] The Great Argument Clinic Conversion Derby Meta-Issue

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I have no any numbers.

--

___
Python tracker 

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

[issue20187] The Great Argument Clinic Conversion Derby Meta-Issue

[Larry Hastings]

Larry Hastings added the comment:

Until you have some numbers, your assertion has no weight and should be ignored.

(As Carl Sagan once wrote: "That which can be asserted without evidence can be 
dismissed without evidence."  And as Donald Knuth wrote: "Premature 
optimization is the root of all evil.")

--

___
Python tracker 

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

[issue20262] Convert some debugging prints in zipfile to warnings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I'm not sure. This is why I had added Larry and Georg to nosy list. This issue 
looks in a half-way between fixing a bug and adding new feature.

--

___
Python tracker 

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

[issue20260] Argument Clinic: add unsigned integers converters

[Larry Hastings]

Larry Hastings added the comment:

We can use this now.  So I bumped it to the top of my queue and reviewed it.  I 
had only minor feedback--thanks!

--

___
Python tracker 

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

[issue20226] Argument Clinic: support for simple expressions?

[Larry Hastings]

Larry Hastings added the comment:

That's okay, email me a sample at

larry at hastings dot org

and I'll take a look at it.  Be sure to tell me which patch(es) were applied at 
the time.

(Note: all you need to send is the Clinic block.)

--

___
Python tracker 

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

[issue19974] tarfile doesn't overwrite symlink by directory

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> patch review

___
Python tracker 

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

[issue19974] tarfile doesn't overwrite symlink by directory

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: patch review -> needs patch

___
Python tracker 

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

[issue20226] Argument Clinic: support for simple expressions?

[Zachary Ware]

Zachary Ware added the comment:

Just confirmed that this patch fixes the traceback I was getting from winreg in 
#20172, but this has a new oddity:

>>> help(winreg)
...
ConnectRegistry(computer_name=, key=)
...

Every param of every function has this kind of thing, positional or keyword, 
default or no.  I'll try to look into it, but my hopes aren't high (much of 
clinic's inner workings are still mysterious to me).

--
nosy: +zach.ware

___
Python tracker 

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

[issue15858] tarfile missing entries due to omitted uid/gid fields

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> test needed
versions: +Python 2.7, Python 3.3, Python 3.4 -3rd party, Python 2.6

___
Python tracker 

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

[issue20226] Argument Clinic: support for simple expressions?

[Larry Hastings]

Larry Hastings added the comment:

I'd prefer it if you emailed me as I asked.  That will help me get to it a lot 
quicker.

--

___
Python tracker 

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

[issue20226] Argument Clinic: support for simple expressions?

[Zachary Ware]

Zachary Ware added the comment:

Actually, I can reproduce on tip with just this patch applied; os.chmod shows 
it.  And I was wrong, params that have a default are correct, it's just ones 
without.

--

___
Python tracker 

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

[issue20241] Bad reference to RFC in document of ipaddress?

[Fran Bull]

Fran Bull added the comment:

http://tools.ietf.org/html/rfc5735.html
Special Use IPv4 Addresses

does indeed agree with the docstring

@property
def is_unspecified(self):
"""Test if the address is unspecified.

Returns:
A boolean, True if this is the unspecified address as defined in
RFC 5735 3.

"""
unspecified_address = IPv4Address('0.0.0.0')
return self == unspecified_address

and makes more sense than http://tools.ietf.org/html/rfc5375.html
IPv6 Unicast Address Assignment Considerations

and so the attached patch will bring them into line.

However it's worth noting that the RFC doesn't say anything about 0.0.0.0 being 
the 'unspecified' address, (the RFC linked for the IPv6 is_unspecified 
http://tools.ietf.org/html/rfc2373.html#section-2.5.2 does specifically call it 
the 'unspecified' address). 5735 3 just says:

3.  Global and Other Specialized Address Blocks

   0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
   network.  Address 0.0.0.0/32 may be used as a source address for this
   host on this network; other addresses within 0.0.0.0/8 may be used to
   refer to specified hosts on this network ([RFC1122], Section
   3.2.1.3).

googling it you can find eg this:

http://en.wikipedia.org/wiki/IPv6_address
says:
 ::/128 — The address with all zero bits is called the unspecified address 
(corresponding to 0.0.0.0/32 in IPv4).

so perhaps this bit of the docs could be a bit clearer, although I don't know 
what it should say, perhaps something like:
'Checks if the address is 0.0.0.0 which corresponds to the unspecified address 
in IPv6'
someone with better networking knowledge than me could say.

--
keywords: +patch
nosy: +Fran.Bull
Added file: http://bugs.python.org/file33482/20241.patch

___
Python tracker 

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

[issue20260] Argument Clinic: add unsigned integers converters

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Unfortunately I have discovered that there is significant difference between 
uint_converter in Modules/zlibmodule.c and proposed 
_PyLong_UnsignedInt_Converter. And there are tests in Lib/test/test_zlib.py 
which fail when _PyLong_UnsignedInt_Converter is used instead of 
uint_converter. uint_converter raises ValueError for negative integers, and 
_PyLong_UnsignedInt_Converter raises OverflowError.

Possible solutions:

1. Change tests. I don't like this, ValueError looks reasonable for these cases.

2. Continue to use uint_converter in Modules/zlibmodule.c. Then new converters 
become less useful.

3. Raise ValueError in new converters for negative integers. ValueError looks 
reasonable in many cases.

4. Raise ValueError in PyLong_AsUnsignedLong etc for negative integers.

Here is a patch which incorporates Larry's suggestions and implements option #3.

--
nosy: +mark.dickinson, skrah
Added file: http://bugs.python.org/file33483/clinic_unsigned_converters.patch

___
Python tracker 

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

[issue20262] Convert some debugging prints in zipfile to warnings

[Georg Brandl]

Georg Brandl added the comment:

I'm actually more on the "fixing a bug" side.  For me this is fine for 3.3.

--

___
Python tracker 

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

[issue20260] Argument Clinic: add unsigned integers converters

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Oh, and of course 5th option: do nothing.

--

___
Python tracker 

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

[issue20232] Argument Clinic NULL default falsely implies None acceptability

[Larry Hastings]

Larry Hastings added the comment:

One mandate I've given myself for this project:

  When a function provides a signature, it must be 100% accurate.

A specific corollary of this:

  If you call a function, and for every optional parameter you
  explicitly pass it in with its default value from the signature,
  the result will be identical with calling the function and not
  providing that optional parameter.

So we can't lie here.

You're right that this is a general problem.  It's possible for a C function to 
accept a parameter that is
 * positional-or-keyword,
 * has a default value, and
 * the default value is not publishable as a Python value.
This is impossible in Python.  But Clinic only allows you to represent 
Python-compatible signatures.

In this *specific* case we can dodge the bullet:

/*[clinic input]
SHA1.SHA1
  string: object(c_default='NULL') = b''

--

___
Python tracker 

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

[issue20272] chain.from_iterable in the overview table not linking to the function

[SilentGhost]

New submission from SilentGhost:

chain.from_iterable is not linkified in the overview table at the top of the 
itertools docs. The patch requires reformat of the table.

--
assignee: docs@python
components: Documentation
files: linkify.diff
keywords: patch
messages: 208184
nosy: SilentGhost, docs@python, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: chain.from_iterable in the overview table not linking to the function
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33484/linkify.diff

___
Python tracker 

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

[issue20272] chain.from_iterable in the overview table not linking to the function

[SilentGhost]

Changes by SilentGhost :


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

[issue20231] Argument Clinic accepts no-default args after default args

[Larry Hastings]

Larry Hastings added the comment:

I'll fix this, but it's lower priority than the new features for Clinic that 
people need in order to get unblocked.

--

___
Python tracker 

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

[issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files

[Larry Hastings]

Larry Hastings added the comment:

In the past few days I added "cloning" functions, which lets you reuse the 
parameters and return converter from an existing function.  That might help 
with Modules/_ctypes/_ctypes.

--

___
Python tracker 

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

[issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files

[Larry Hastings]

Larry Hastings added the comment:

All the functions in curses_panel are convertable.  The threeMETH_NOARGS 
functions simply get no arguments.  And here's new_panel:

new_panel
  window: object(subclass_of='&PyCursesWindow_Type')
  /

--

___
Python tracker 

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

[issue20273] Argument Clinic: unhelpful crashes

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Sometimes when Argument Clinic see something wrong, it raises exception and 
exit with printed traceback, instead of output helpful error message which 
points on line with illegal syntax.

I open this issue to report about such problems.

$ ./python Tools/clinic/clinic.py -f Modules/zlibmodule.c
Traceback (most recent call last):
  File "Tools/clinic/clinic.py", line 3032, in 
sys.exit(main(sys.argv[1:]))
  File "Tools/clinic/clinic.py", line 3028, in main
parse_file(filename, output=ns.output, verify=not ns.force)
  File "Tools/clinic/clinic.py", line 1135, in parse_file
cooked = clinic.parse(raw)
  File "Tools/clinic/clinic.py", line 1085, in parse
parser.parse(block)
  File "Tools/clinic/clinic.py", line 2262, in parse
self.state(line)
  File "Tools/clinic/clinic.py", line 2582, in state_parameter
value = eval(py_default)
  File "", line 1, in 
NameError: name 'zlib' is not defined

zlibmodule.c is almost same as after applying patch from issue20193 (with 
several clinic bugs already fixed).

--
components: Demos and Tools
messages: 208188
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: unhelpful crashes
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue20274] sqlite module has bad argument parsing code, including undefined behavior in C

[Larry Hastings]

New submission from Larry Hastings:

The code in Modules/_sqlite/connection.c is sloppy.

The functions pysqlite_connection_execute, pysqlite_connection_executemany, and 
pysqlite_connection_executescript accept a third "PyObject *kwargs".  However 
none of these functions are marked METH_KEYWORD.  This only works because the 
kwargs parameter is actually ignored--the functions only support 
positional-only arguments.  Obviously the "PyObject *kwargs" parameters should 
be removed for these three functions.

A slightly more advanced problem: pysqlite_connection_call, which implements 
sqlite3.Connection.__call__(), ignores its kwargs parameter completely.  If it 
doesn't accept keyword parameters it should at least complain if any are passed 
in.

Georg: you want this fixed in 3.3?  3.2?
Benjamin: you want this fixed in 2.7?

--
messages: 208189
nosy: benjamin.peterson, georg.brandl, larry
priority: normal
severity: normal
stage: needs patch
status: open
title: sqlite module has bad argument parsing code, including undefined 
behavior in C
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue20273] Argument Clinic: unhelpful crashes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I suppose this crash is caused by this code:

/*[clinic input]
zlib.Compress.flush

self: self(type="compobject *")
mode: int(c_default="Z_FINISH") = zlib.Z_FINISH
One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH.
If mode == Z_FINISH, the compressor object can no longer be used after
calling the flush() method.  Otherwise, more data can still be 
compressed.
/

Return a bytes object containing any remaining compressed data.
[clinic start generated code]*/

It was valid several days ago.

Therefore here are two bugs:

1. Argument Clinic should output a line number where it has encountered illegal 
expression.

2. It should accept zlib.Z_FINISH (Z_FINISH is exported constant in the zlib 
module).

--

___
Python tracker 

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

[issue20274] sqlite module has bad argument parsing code, including undefined behavior in C

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue8876] distutils should not assume that hardlinks will work

[Larry Hastings]

Larry Hastings added the comment:

Has this been fixed?

--

___
Python tracker 

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

[issue20273] Argument Clinic: unhelpful crashes

[Larry Hastings]

Larry Hastings added the comment:

I'm marking this as a duplicate of #20226, the "add general-purpose 
expressions" issue, because that will fix the behavior you're seeing.  As for 
"in general Argument Clinic should have better error reporting", this is too 
general for an issue right now.  In the future feel free to file issues for 
specific badly-phrased errors.

--
assignee:  -> larry
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +Argument Clinic: support for simple expressions?

___
Python tracker 

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

[issue20235] Argument Clinic: recover a bit more gracefully from exceptions

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue20273] Argument Clinic: unhelpful crashes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Zachary.

--

___
Python tracker 

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

[issue20273] Argument Clinic: unhelpful crashes

[Zachary Ware]

Zachary Ware added the comment:

Georg already opened an issue with a patch about providing a little more 
information in unexpected exceptions, see issue20235.

--
nosy: +zach.ware
superseder:  -> Argument Clinic: support for simple expressions?

___
Python tracker 

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

[issue20235] Argument Clinic: recover a bit more gracefully from exceptions

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM. This patch helps me (issue20273). Thank you.

--
components: +Demos and Tools
stage:  -> commit review
type:  -> enhancement
versions: +Python 3.4

___
Python tracker 

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

[issue20235] Argument Clinic: recover a bit more gracefully from exceptions

[Larry Hastings]

Larry Hastings added the comment:

LGTM, please commit.

--

___
Python tracker 

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

[issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows)

[Zachary Ware]

Zachary Ware added the comment:

About cloning:

Cloned functions still expect their own impl function.  In current winreg, 
OpenKey and OpenKeyEx literally are the same function by two names; is the best 
approach for this to define winreg_OpenKeyEx_impl as `return 
winreg_OpenKey_impl(module, key, sub_key, reserved, access);`?

As stated in #20226, that patch works fine with my conversions.  Once the 20226 
patch lands, I'll get a comprehensive patch for this issue posted.  Until then, 
I've branched the sandbox repo yet again; future_clinic_20172 contains the 
20226 patch, along with the necessary updates to these files and further 
changes using the new features that aren't in trunk yet.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

New submission from Yury Selivanov:

Can we remove debug timing around "self._selector.select(timeout)"
(or at least make it configurable) from BaseEventLoop?

Right now the code is:

# TODO: Instrumentation only in debug mode?
t0 = self.time()
event_list = self._selector.select(timeout)
t1 = self.time()
argstr = '' if timeout is None else ' {:.3f}'.format(timeout)
if t1-t0 >= 1:
level = logging.INFO
else:
level = logging.DEBUG
logger.log(level, 'poll%s took %.3f seconds', argstr, t1-t0)

So it makes two 'time.time()' calls per loop iteration, plus
one "logging.log" call.

The only non-intrusive solution that I can suggest is to add a
class attribute '_debug' to BaseEventLoop, set to False by default
(unittests can set it to True in their setUp methods).

--
components: Library (Lib)
messages: 208199
nosy: gvanrossum, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: remove debug code from BaseEventLoop
type: performance
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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

And I'd be happy to help with the patch.

--

___
Python tracker 

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

[issue20260] Argument Clinic: add unsigned integers converters

[Stefan Krah]

Stefan Krah added the comment:

I think we cannot change PyLong_AsUnsignedLong() without a deprecation period,
if at all.  That leaves the option of changing the converters.

My preference is to raise either OverflowError or ValueError for *both*
out-of-range conditions.

People may me used to OverflowError by now -- the usage in 
PyLong_AsUnsignedLong()
dates back to very early revisions -- but there are equally good reasons to use
ValueError.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Guido van Rossum]

Guido van Rossum added the comment:

What part of the debug timing is more expensive than the select call itself?

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[STINNER Victor]

STINNER Victor added the comment:

I'm also in favor of removing this code, or a debug flag to enable it.

--
nosy: +haypo

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Guido van Rossum]

Guido van Rossum added the comment:

Can you check for the level of the logger? That would work for me.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Guido van Rossum]

Guido van Rossum added the comment:

So you admit you just want to optimize prematurely?

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

> What part of the debug timing is more expensive than the select call itself?

Well, there is nothing really expensive there, but:

- time.monotonic() is still a syscall
- logging.log executes a fair amount of code too

--

___
Python tracker 

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

[issue20274] sqlite module has bad argument parsing code, including undefined behavior in C

[R. David Murray]

R. David Murray added the comment:

Why do you want to fix it in order versions?  Can it lead to a crash?

For __call__, it seems to me we should do a deprecation and remove it in 3.5.  
Otherwise we'll risk breaking working code for no good reason (working code 
with useless parameters, but still working code :)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[STINNER Victor]

STINNER Victor added the comment:

> So you admit you just want to optimize prematurely?

I don't understand the purpose of these timing information, I don't use them. I 
would be more interested to know which functions take longer than XXX ms and so 
hangs the event loop.

By the way, it's not documentation how to enable asyncio logs:
http://docs.python.org/dev/library/asyncio.html

The asyncio logger is not documented. I would like to add a section listing 
development tools like asyncio.tasks._DEBUG=True and the "Future/Task exception 
was never retrieved" log.

Hum, it looks like asyncio.futures.STACK_DEBUG is not used.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

I wrote a small micro-benchmark, that creates 100K tasks and executes them.

With debug code the execution time is around 2.8-3.1s, with debug comment 
commented out it's around 2.3-2.4s.

Again, it's a micro-benchmark, and in a real application the impact is going to 
be much smaller.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

The micro-benchmark i used is here: https://gist.github.com/1st1/8446175

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[STINNER Victor]

STINNER Victor added the comment:

> With debug code the execution time is around 2.8-3.1s, with debug comment 
> commented out it's around 2.3-2.4s.

Wow, that's impressive that such minor syscalls can take so much times!

I modified your script to repeat the test 5 times and take the minimum timing:

* Python 3.4 original: 3.83 seconds
* asyncio without timing log: 2.79 seconds (27% faster)

27% faster is not a "premature" optimisation :-)

By the way, Linux provides faster clocks like CLOCK_MONOTONIC_COARSE:

   A  faster  but  less  precise version of CLOCK_MONOTONIC.
   Use when you need very fast, but not  fine-grained  time‐
   stamps.

Python doesn't expose these clock identifiers yet: #14555.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Guido van Rossum]

Guido van Rossum added the comment:

I have definitely used this log message.  It typically tells me that something 
is responding too slow.

Regarding the microbench, please count and report how many times it actually 
calls select().

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

> Wow, that's impressive that such minor syscalls can take so much times!

Apparently, it's not syscalls, it's logging.

Actually, with commented out "logging.log" code I can't see a difference wether 
there are calls to monotonic or not.

So we can keep the code as is, let's just log something when select takes 
longer than 1 second (and log nothing when it's faster)

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
Added file: http://bugs.python.org/file33485/debug_flag.patch

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[STINNER Victor]

STINNER Victor added the comment:

Here are two patches:

- logger_is_enabled_for.patch: use logger.isEnabledFor(INFO) to avoid the call
- add a _debug flag to BaseEventLoop

Benchmark:

- original: 3.90
- logger: 3.04
- _debug: 2.81

I like the _debug flag because it's faster, but I'm not sure that an attribute 
is the best place for the flag. asyncio needs maybe one global debug flag (ex: 
asyncio._DEBUG=True) replacing the existing asyncio.tasks._DEBUG flag.

--
Added file: http://bugs.python.org/file33486/logger_is_enabled_for.patch

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

> Regarding the microbench, please count and report how many times it actually 
> calls select().

I'm on MacOS X, so it's KqueueSelector. It's 'select' method (and 
self._kqueue.control respectively) is called twice more times. So for 100K 
tasks, select gets called 200K. But that's just the way my benchmark is written.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

Victor,

Re your patch: since it's not really time syscalls, and Guido said he's using 
this debug code, how about we just have something like:

t0 = self.time()
event_list = self._selector.select(timeout)
t1 = self.time()
if t1 - t0 >= 1:
argstr = '' if timeout is None else ' {:.3f}'.format(timeout)
level = logging.INFO
logger.log(level, 'poll%s took %.3f seconds', argstr, t1-t0)

?

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Guido van Rossum]

Guido van Rossum added the comment:

I like logger_is_enabled_for.patch.

If you want to add other debug features please propose something on the Tulip 
tracker: http://code.google.com/p/tulip/issues/list .

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

And, I think that "asyncio._DEBUG" or even "asyncio.DEBUG" would be a great 
idea.

--

___
Python tracker 

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

[issue18373] implement sys.get/setbyteswarningflag()

[Jakub Wilk]

Changes 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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

Victor, Guido,

Please take a look at the attached one.
I believe it's slightly better, than the "logger_is_enabled_for.patch", since 
it doesn't log stuff that was faster than 1 second, and is simpler too.

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Changes by Yury Selivanov :


Added file: http://bugs.python.org/file33487/greater_than_1sec_logging.patch

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Changes by Yury Selivanov :


Removed file: http://bugs.python.org/file33487/greater_than_1sec_logging.patch

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Changes by Yury Selivanov :


Added file: http://bugs.python.org/file33488/greater_than_1sec_logging.patch

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[STINNER Victor]

STINNER Victor added the comment:

I opened an issue to propose asyncio.DEBUG:
BaseEventLoop._run_once()

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy:  -pitrou

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Guido van Rossum]

Guido van Rossum added the comment:

I really want to log the time every time if level == DEBUG and only if > 1 sec 
for other levels, so maybe all you need to do is remove the comment? :-)  (Or 
maybe logger.isEnabledFor(logging.INFO) is faster than logger.log() when 
nothing gets logged?

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[STINNER Victor]

STINNER Victor added the comment:

I opened an issue to propose asyncio.DEBUG:
http://code.google.com/p/tulip/issues/detail?id=104

(woops, copy/paste failure :-))

--

___
Python tracker 

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

[issue20275] asyncio: remove debug code from BaseEventLoop

[Yury Selivanov]

Yury Selivanov added the comment:

> I really want to log the time every time if level == DEBUG and only if > 1 
> sec for other levels, so maybe all you need to do is remove the comment? :-)  
> (Or maybe logger.isEnabledFor(logging.INFO) is faster than logger.log() when 
> nothing gets logged?

Well, in this case, I think if async.DEBUG is accepted, than Victor can apply 
his "debug_flag.patch" (with some modifications), and if not, then his 
"logger_is_enabled_for.patch" would work for you too.

--

___
Python tracker 

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

[issue20274] sqlite module has bad argument parsing code, including undefined behavior in C

[Larry Hastings]

Larry Hastings added the comment:

You're right, deprecation sounds best.  If Georg or Benjamin want the fix in 
earlier releases I'll split the pysqlite_connection_call into another issue, 
otherwise I won't bother.

As for fixing the undefined behavior in older versions: since its behavior is 
undefined, yes, it *could* cause a crash.  But by that token it *could* 
teleport you to Mars and give you a funny-looking nose.  In practice it 
*should* be utterly harmless, as I believe every platform supported by Python 
3.4 uses the caller-pops-stack calling convention.  And we've lived with it for 
this long, so it doesn't seem to be hurting anything.  But like all undefined 
behavior I can make no guarantee.

MvL in particular comes down like a ton of bricks whenever someone proposes 
checking in code that's technically undefined behavior.  I've had the relevant 
chapter and verse of the C standard quoted at me for this exact thing (calling 
a function pointer using a slghtly different signature than the actual 
function).

--

___
Python tracker 

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

[issue15858] tarfile missing entries due to omitted uid/gid fields

[Tom Lynn]

Tom Lynn added the comment:

The secondary issue, which the patch doesn't address, is that TarFile.next() 
seems unpythonic; it treats any {Invalid,Empty,Truncated}HeaderError after 
offset 0 as EOF rather than propagating the exception.  It looks deliberate, 
but I'm not sure why it would be done like that or if it should be changed.

--

___
Python tracker 

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

[issue20276] ctypes._dlopen should not force RTLD_NOW

[Albert Zeyer]

New submission from Albert Zeyer:

On MacOSX, when you build an ARC-enabled Dylib with backward compatibility for 
e.g. MacOSX 10.6, some unresolved functions like 
`_objc_retainAutoreleaseReturnValue` might end up in your Dylib.

Some reference about the issue:
1. http://stackoverflow.com/q/21119425/133374>.
2. http://osdir.com/ml/python.ctypes/2006-10/msg00029.html
3. https://groups.google.com/forum/#!topic/comp.lang.python/DKmNGwyLl3w

Thus, RTLD_NOW is often not an option for MacOSX.

This affects mostly `py_dl_open()` from ctypes.
But it is also related how you set `dlopenflags` in `PyInterpreterState_New()`.

I suggest to make RTLD_LAZY the default on MacOSX (or is there a good reason 
not to do?).
Also, ctypes should have options for both RTLD_NOW and RTLD_LAZY so that both 
can be used.

This is also consistent with the behavior of the [dl 
module](http://docs.python.org/2/library/dl.html).

--
components: ctypes
messages: 208226
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: ctypes._dlopen should not force RTLD_NOW
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

[issue20276] ctypes._dlopen should not force RTLD_NOW

[STINNER Victor]

Changes 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

[issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files

[Ryan Smith-Roberts]

Ryan Smith-Roberts added the comment:

Forgot to linewrap a paragraph.

--
Added file: 
http://bugs.python.org/file33489/argument_clinic_socketmodule_v2.patch

___
Python tracker 

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

[issue20189] inspect.Signature doesn't recognize all builtin types

[Larry Hastings]

Larry Hastings added the comment:

Nick, could you maybe review this?

--
nosy: +ncoghlan

___
Python tracker 

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

[issue20260] Argument Clinic: add unsigned integers converters

[Larry Hastings]

Larry Hastings added the comment:

I'm glad you caught that!  First things first: the converted code should behave 
identically to the existing code, including raising the same exceptions.


If you examine the exception hierarchy:
http://docs.python.org/3.4/library/exceptions.html#exception-hierarchy

you'll see that "OverflowError" is a subclass of "ArithmeticError".  In other 
words, it represents when you perform an arithmetic operation that overflows 
the result type.  Using it to also represent "you specified a value that is out 
of range for this conversion" seems wrong.

So I like #3 as well.

Could _PyLong_UnsignedInt_Converter catch the OverflowError raised by 
PyLong_AsUnsignedLong and reraise it as ValueError?

--

___
Python tracker 

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

[issue20276] ctypes._dlopen should not force RTLD_NOW

[Ned Deily]

Changes by Ned Deily :


--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue20227] Argument Clinic: rename arguments in generated C?

[Larry Hastings]

Larry Hastings added the comment:

I don't see the big win from this.  You can rename variables in C any way you 
like.  "functionname as c_basename" is to fix otherwise unavoidable collisions; 
this seems like a nice-to-have.  And I already have a lot on my plate.  I could 
consider it later but the priority for this is below converting functions.

Georg: I remind you that nearly every parsing function already has a variable 
called "args".  To allow you to have a parameter called "args" would mean I'd 
have to have really complicated internal structure, where
the variable I declare in the parsing function would have a different
name from the parameter to the impl function.  Do you really have a
burning, nearly incandescent need for this feature?

Zachary: You could minimize the size of the diff by using nested scopes:

_impl(...)
/*[clinic end generated code: checksum=...]*/
{
   int use_overlapped = overlapped;
   {
   LP_OVERLAPPED overlapped;
   ...

--

___
Python tracker 

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