[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

> Please either 
> 1) drop the throw() method entirely or
> 2) make throw an abstractmethod()

Ok, as I already said, I think it's important to provide the complete protocol 
as code will usually expect that. Also, close() has a helpful implementation, 
but it depends on throw(). Thus, I'll go with 2) and make throw() abstract. 
It's easy enough to call super(), but then it's explicit. I agree that that's 
better here.

Patch updated.

--
Added file: http://bugs.python.org/file39213/generator_abc.patch

___
Python tracker 

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

[issue9858] Python and C implementations of io are out of sync

[Laura Rupprecht]

Laura Rupprecht added the comment:

There were originally three methods present in RawIOBase that were not present 
in PyRawIOBase_Type:

1. readinto
2. write
3. __weakref__

I've created a patch that adds the first two to PyRawIOBase_Type. The python 
class readinto and write methods raise UnsupportedOperation, so the c methods 
return a PyExc_NotImplementedError.

The next major question I have is whether we need to implement a __weakref__ 
method or this should be ignored in the test.

--
keywords: +patch
nosy: +laura
Added file: http://bugs.python.org/file39212/issue9858.patch

___
Python tracker 

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

[issue23955] Add python.ini file for embedded/applocal installs

[Steve Dower]

Steve Dower added the comment:

Having looked at the implementation, the easiest way to do this will be to add 
an "applocal = true" option to pyvenv.cfg, which would behave identically to 
setting %PYTHONHOME% to the directory containing the config before launch.

I wanted to support relative paths for "home = " but the path handling is so 
far from sufficient that it wouldn't be secure. As it is, I've fixed a lot of 
potential buffer overruns in getpathp.c already, but I don't want to implement 
true relative paths, so I'd prefer to require "home = " to be absolute and add 
a second property that effectively means "home = .".

Any thoughts/comments/preferences?

--

___
Python tracker 

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

[issue23970] Update distutils.msvccompiler for VC14

[Steve Dower]

Steve Dower added the comment:

Made some updates to the patch to use the existing infrastructure for setting 
include and library paths, and to fix bdist_wininst.

While it may be worth doing more significant restructuring to help people with 
overriding aspects of build, that's almost certainly something that would be 
better done in a separate build tool. This patch is really just focused on 
getting the bare minimum support (distutils) working with the changed compiler 
and some cleanup to make it easier to maintain.

--
Added file: http://bugs.python.org/file39211/msvccompiler_2.patch

___
Python tracker 

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

[issue23668] Support os.ftruncate on Windows

[Steve Dower]

Changes by Steve Dower :


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

[issue24064] Make the property doctstring writeable

[Raymond Hettinger]

New submission from Raymond Hettinger:

I can't see any reason for property docstrings to be readonly:

>>> p = property(doc='basic')
>>> p.__doc__
'basic'
>>> p.__doc__ = 'extended'
Traceback (most recent call last):
  File "", line 1, in 
p.__doc__ = 'extended'
AttributeError: readonly attribute

Among other things, making it writeable would simplify the ability to update 
the docstrings produced by namedtuple;

Time.mtime.__doc__ = 'modification time'
Score.max = 'all time cumulative high score for a single season'

--
components: Interpreter Core
keywords: easy
messages: 242098
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Make the property doctstring writeable
type: enhancement
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

[issue23749] asyncio missing wrap_socket

[Elizabeth Myers]

Elizabeth Myers added the comment:

For what it's worth, IRC has an optional STARTTLS extension which is 
implemented by some servers. IMAP and SMTP also have STARTTLS as a fundamental 
component of their protocols. As gc pointed out, LDAP also supports it.

IMO this is a pretty glaring omission.

--

___
Python tracker 

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

[issue16669] Docstrings for namedtuple

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, here's a proposed new classmethod that makes it possible to easily 
customize the field docstrings but without cluttering the API of the factory 
function:

@classmethod
def _set_docstrings(cls, **docstrings):
'''Customize the field docstrings

   >>> Point = namedtuple('Point', ['x', 'y'])
   >>> Point._set_docstrings(x = 'abscissa', y = 'ordinate')
   
'''
for fieldname, docstring in docstrings.items():
if fieldname not in cls._fields:
raise ValueError('Fieldname %r does not exist' % fieldname)
new_property = _property(getattr(cls, fieldname), doc=docstring)
setattr(cls, fieldname, new_property)


Note, nothing is needed for the main docstring since it is already writeable:

 Point.__doc__ = '2-D Coordinate'

--

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Elizabeth Myers]

Elizabeth Myers added the comment:

What needs to be done to make this happen? I can try to implement it.

--
nosy: +Elizacat

___
Python tracker 

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

[issue24018] add a Generator ABC

[Guido van Rossum]

Guido van Rossum added the comment:

I'm with Raymond.

--

___
Python tracker 

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

[issue23910] C implementation of namedtuple (WIP)

[Joe Jevnik]

Joe Jevnik added the comment:

This was very exciting, I have never run gprof before; so just to make sure I 
did this correctly, I will list my steps:

1. compile with the -pg flag set
1. run the test with ./python -m timeit ...
1. $ gprof python gmon.out > profile.out

Here is default:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  Ts/call  Ts/call  name
 22.48  0.87 0.87 PyEval_EvalFrameEx
  9.82  1.25 0.38 
PyObject_CallFunctionObjArgs
  6.85  1.52 0.27 PyObject_GenericGetAttr
  6.46  1.77 0.25 tupledealloc
  5.56  1.98 0.22 PyArg_UnpackTuple
  5.17  2.18 0.20 PyNumber_AsSsize_t
  5.17  2.38 0.20 tuplesubscript
  5.04  2.58 0.20 PyObject_Call
  4.91  2.77 0.19 _PyType_Lookup
  4.65  2.95 0.18 PyTuple_New
  4.65  3.13 0.18 PyObject_GetItem
  4.39  3.30 0.17 itemgetter_call
  1.94  3.37 0.08 PyObject_GetAttr
  1.81  3.44 0.07 PyObject_GC_UnTrack
  1.81  3.51 0.07 _PyTuple_DebugMallocStats
  1.03  3.55 0.04 PyErr_Occurred
  1.03  3.59 0.04 property_descr_set
  1.03  3.63 0.04 tuplerepr
  0.78  3.66 0.03 PyLong_AsSsize_t
  0.78  3.69 0.03 PyObject_GC_Track
  0.52  3.71 0.02 property_descr_get
  0.52  3.73 0.02 repeat_next
  0.52  3.75 0.02 repeat_traverse
  0.39  3.77 0.02 
PyArg_ValidateKeywordArguments
  0.39  3.78 0.02 _Py_CheckFunctionResult
  0.26  3.79 0.01 PyCFunction_NewEx
  0.26  3.80 0.01 PyCode_New
  0.26  3.81 0.01 PyErr_Restore
  0.26  3.82 0.01 PyType_GetSlot
  0.26  3.83 0.01 
_PyObject_CallMethodIdObjArgs
  0.26  3.84 0.01 attrgetter_new
  0.26  3.85 0.01 update_one_slot
  0.13  3.86 0.01 
_PyObject_GenericGetAttrWithDict
  0.13  3.86 0.01 _PyObject_SetAttrId
  0.13  3.87 0.01 gc_isenabled
  0.13  3.87 0.01 visit_decref


Here is my patch:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls  Ts/call  Ts/call  name
 26.63  1.02 1.02 PyEval_EvalFrameEx
  8.88  1.36 0.34 PyObject_GenericGetAttr
  7.83  1.66 0.30 tupledealloc
  6.27  1.90 0.24 PyObject_Call
  5.74  2.12 0.22 PyTuple_New
  5.48  2.33 0.21 property_descr_get
  5.22  2.53 0.20 _PyType_Lookup
  4.44  2.70 0.17 tuplesubscript
  4.18  2.86 0.16 PyArg_UnpackTuple
  3.92  3.01 0.15 PyNumber_AsSsize_t
  3.66  3.15 0.14 PyObject_GetItem
  2.87  3.26 0.11 itemgetter_call
  2.61  3.36 0.10 PyObject_GC_UnTrack
  1.70  3.43 0.07 PyObject_GetAttr
  1.31  3.48 0.05 repeat_next
  1.31  3.53 0.05 repeat_traverse
  1.04  3.57 0.04 attrgetter_new
  1.04  3.61 0.04 property_descr_set
  0.78  3.64 0.03 PyErr_Occurred
  0.78  3.67 0.03 PyErr_Restore
  0.78  3.70 0.03 PyLong_AsSsize_t
  0.78  3.73 0.03 PyType_GetSlot
  0.52  3.75 0.02 PyObject_GC_Track
  0.26  3.76 0.01 
PyArg_ValidateKeywordArguments
  0.26  3.77 0.01 P

[issue22619] Possible implementation of negative limit for traceback functions

[Robert Collins]

Robert Collins added the comment:

Nice, looks pretty elegant to me. I have nothing to add to the prior reviewers 
comments.

--

___
Python tracker 

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

[issue23910] C implementation of namedtuple (WIP)

[Raymond Hettinger]

Raymond Hettinger added the comment:

If you have a chance, run a C profiler so we can see whether most of the time 
is being spent in an attribute lookup for the current property(itemgetter) 
approach versus your nt-indexer approach.  Without a profile, I have only my 
instincts that the overhead is a mix of indirections and function call overhead 
(both solveable by in-lining), and over-generalization for all 
PyObject_GetItem() (solvable by specialization to a tuple subclass), and 
variable length argument lists (solveable by using of PyTuple_New(1)).   

Ideally, I would like something that speeds-up broader swaths of the language 
and doesn't obfuscate the otherwise clean generated code.  ISTM that the C code 
for both property() and itemgetter() still have room to optimize the common 
case.

--

___
Python tracker 

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

[Christie]

Christie added the comment:

@serhiy.storchaka - just double checking, do you guys need me to make any more 
changes to the patch?

And is there any more review needed, or is it possible for this to be merged?

Thanks very much!

--

___
Python tracker 

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

[issue23910] C implementation of namedtuple (WIP)

[Joe Jevnik]

Joe Jevnik added the comment:

I was unable to see a performance increase by playing with the 
itemgetter.__call__ code; however, updating the propery code seemed to show a 
small improvement. I think that for simple indexing the cost of checking if it 
is a sequence outways the faster dispatch (when using PySequence_GetItem). I 
can play with this further.

* default
[joejev@Sheila cpython]$ ./python -m timeit -s "from collections import 
namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" "a.a"
1000 loops, best of 3: 0.101 usec per loop

* patch
[joejev@Sheila cpython]$ ./python -m timeit -s "from collections import 
namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" "a.a"
1000 loops, best of 3: 0.0942 usec per loop

--
Added file: http://bugs.python.org/file39210/property.patch

___
Python tracker 

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

[issue24061] Python 2.x breaks with address sanitizer

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4234b0dd2a54 by Benjamin Peterson in branch '2.7':
allow 2.7 to be built with asan (closes #24061)
https://hg.python.org/cpython/rev/4234b0dd2a54

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue24018] add a Generator ABC

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Therefore, I think it's important to cover the complete protocol 
> in the Generator ABC. I also think it's helpful to not require
> users to override throw() in a subclass, as they might not need it.

Sorry, but I think you're fighting the fundament nature of what the ABCs are 
supposed to do and I object to the patch going in as-is.  

Please either 
1) drop the throw() method entirely or
2) make throw an abstractmethod()

If it is an abstractmethod, the user is free to implement a throw() method that 
raises a NotImplementedError, but at least they will do so consciously rather 
than having it come-up expectedly.

When I teach engineers how to use the collections ABCs, they rely on the rules:

 * when building a class that inherits from an ABC,
   if you supply the required abstract methods,
   then the mixin method just work.

 * if an object passes the isinstance check, 
   then it is fair game to call any of the listed
   methods an expect it to work.

Until now, those rules were followed by all the ABCs.  I really don't want to 
break the basic contract of what the ABC is supposed to mean.

--
assignee: lukasz.langa -> rhettinger

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Yury Selivanov added the comment:

In fact I will likely add tp_await in the next PEP iteration. I need it to 
implement another feature.

--

___
Python tracker 

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

[issue23910] C implementation of namedtuple (WIP)

[Raymond Hettinger]

Raymond Hettinger added the comment:

One other thought: the itemgetter.__call__ method is already pretty thin:

if (!PyArg_UnpackTuple(args, "itemgetter", 1, 1, &obj))
return NULL;
if (nitems == 1)
return PyObject_GetItem(obj, ig->item);

But you could add a special case for single integer index being applied to a 
known sequence.  Extract the Py_ssize_t index in itemgetter_new and store it in 
the itemgetterobject.  Then add a fast path in itemgetter.__call__.  Roughly 
something like this:

  if (ig->index != -1 &&
  PyTuple_Check(obj) && 
  nitems == 1 &&
  PyTuple_GET_SIZE(obj) > ig->index) {
   result = PySequence_Fast_GET_ITEM(obj, ig->index);
   Py_INCREF(result);
   return result;
  }
 
Perhaps also add a check to make sure the tuple subclass hasn't overridden the 
__getitem__ method (see an example of how to do this in the code for 
Modules/_collectionsmodule.c::_count_elements()).

Something along these lines would allow all the steps to be inlined and would 
eliminate all the usual indirections inherent in the abstract API.

Another alternative is to use the PySequence API instead of the PyTuple API.  
That trades away a little of the speed-up in return for speeding-up itemgetter 
on lists as well as tuples.

--

___
Python tracker 

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

[issue24050] [2.7] crash in third party module mopidy

[STINNER Victor]

STINNER Victor added the comment:

mopidy is not maintained by Python. Report the bug to mopidy authors:
https://www.mopidy.com/

--
nosy: +haypo
resolution:  -> not a bug
status: open -> closed
title: Segmentation fault (core dumped) -> [2.7] crash in third party module 
mopidy

___
Python tracker 

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

[issue22057] The doc say all globals are copied on eval(), but only __builtins__ is copied

[Antti Haapala]

Antti Haapala added the comment:

+1 for this patch, the current documentation states it very wrong.

--
nosy: +ztane

___
Python tracker 

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

[issue24061] Python 2.x breaks with address sanitizer

[Ned Deily]

Changes by Ned Deily :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue23910] C implementation of namedtuple (WIP)

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, the current property(itemgetter(index)) code has a Python creation step, 
but the actual attribute lookup and dispatch is done entirely in C (no pure 
python steps around the eval lookup).

Rather than making a user visible C hack directly to namedtuple, any 
optimization effort should be directly at improving the speed of property() and 
itemgetter().

Here are some quick notes to get you started:

* The overhead of property() is almost nothing.
* The code for property_descr_get() in Objects/descrobject.c
* It has two nearly zero cost predictable branches
* So the the only real work is a call to 
  PyObject_CallFunctionObjArgs(gs->prop_get, obj, NULL);
* which then calls both
   objargs_mktuple(vargs) 
  and 
   PyObject_Call(callable, args, NULL);
* That can be sped-up by using 
   PyTuple_New(1)
  and a direct call to  PyObject_Call()
* The logic in PyObject_Call can potentially be tightened
  in the context of a property(itemgetter(index)) call.
  Look to see whether recursion check is necessary
  (itemgetter on a tuple subclass that doesn't extend __getitem__
   is non-recursive)
* If so, then entire call to PyObject_Call() in property 
  can potentially be simplified to:
   result = (*call)(func, arg, kw);

I haven't looked too closely at this, but I think you get the general idea.  If 
the speed of property(itemgetter(index)) is the bottleneck in your code, the 
starting point is to unwind the exact series of C steps performed to see if any 
of them can be simplified.  For the most part, the code in property() and 
itemgetter() were both implemented using the simplest C parts of the C API 
rather than the fastest.  The chain of calls isn't specialized for the common 
use case (i.e. property_get() needing exactly 1 argument rather than a variable 
length arg tuple and itemgetter doing a known integer offset on a list or tuple 
rather than the less common case of generic types and a possible tuple of 
indices).   

We should start by optimizing what we've already got.  That will have a benefit 
beyond named tuples (faster itemgetters for sorting and faster property gets 
for the entire language).  

It also helps us avoid making the NT code less familiar (using custom private 
APIs rather than generic, well-known components).  

It also reduces the risk of breaking code that relies on the published 
implementation of named tuple attribute lookups (for example, I've seen 
deployed code that customizes the attribute docstrings like this):
   Point = namedtuple('Point', ['x', 'y']) 
   Point.x = property(Point.x.fget, doc='abscissa')
   Point.y = property(Point.y.fget, doc='ordinate')
   coordinate = Point(x=250, y=43)

--
priority: normal -> low

___
Python tracker 

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

[issue22881] show median in benchmark results

[Wolfgang Maier]

Wolfgang Maier added the comment:

ah sorry, it's late here already and I forgot what file this change is about. 
So forget my last comment then.

--

___
Python tracker 

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

[issue22881] show median in benchmark results

[Wolfgang Maier]

Wolfgang Maier added the comment:

> It's not available in older Python versions, e.g. 2.6.

I know, I was talking about 3.5+, of course. This would not be backported to 
Python2 anyway, would it?

--

___
Python tracker 

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

[issue22881] show median in benchmark results

[Stefan Behnel]

Stefan Behnel added the comment:

> In general, wouldn't it be good to let the statistics module do all the stats 
> calculations?

It's not available in older Python versions, e.g. 2.6.

--

___
Python tracker 

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

[issue22881] show median in benchmark results

[Wolfgang Maier]

Wolfgang Maier added the comment:

for the even number case, I think you shouldn't do // 2, but / 2.

In general, wouldn't it be good to let the statistics module do all the stats 
calculations?

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Stefan Behnel]

Stefan Behnel added the comment:

PEP 342 isn't really conclusive here as it intended to define the protocol 
based on the de-facto design of a yield-based generator function. Trying to 
abstract from that poses the question how a class based generator 
implementation should look like. Specifically, it is not clear in this case 
what "raise an exception *inside* the generator" even means.

As Antoine pointed out, there definitely has to be more than an Iterator. 
However, it's not clear that throw() and close() are always required for an 
implementation. Simple Generators might get away without special error handling 
and cleanup.

Similarly, a Generator may not allow (or expect) values to be passed in and 
only make use of close() for cleanup (and potentially also throw()).

So, there seem to be at least three use cases for the Generator protocol here:

1) an Iterator that can accept input values via send()
2) an Iterator that needs to safely do certain cleanup operations after use 
(throw/close)
3) a complete Generator that accepts input values and cleans up after it

Given that there used to be only one implementation, I think we can assume that 
a lot of code depends on the complete protocol. Some recipients will certainly 
be aware of the exact subset of the protocol that the Generator they have in 
their hands makes use of, but if they don't, they'll just have to assume it 
supports everything and requires proper cleanup on errors and on termination.

Therefore, I think it's important to cover the complete protocol in the 
Generator ABC. I also think it's helpful to not require users to override 
throw() in a subclass, as they might not need it. "Throwing an exception inside 
of them" might simply not have a meaning for them. If they do need it, however, 
then the current implementation might help them to properly raise the 
exception, given that the 3-argument raise statement is no longer available in 
Py3.

Both reasons (whether you need throw() or not) make me think that it should not 
be abstract. The same applies to close(), which has a meaningful implementation 
now that subclasses can make use of in order to avoid having to implement both 
close() and throw().

And yes, this is about sneaking past generator type checks because most of them 
are actually *not* there for a reason. Asyncio is just one example.

--

___
Python tracker 

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

[issue22881] show median in benchmark results

[Wolfgang Maier]

Changes by Wolfgang Maier :


--
nosy: +wolma

___
Python tracker 

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

[issue23796] BufferedReader.peek() crashes if closed

[John Hergenroeder]

John Hergenroeder added the comment:

It looks like my contributor form has gone through -- what should my next steps 
here be? Thanks!

--

___
Python tracker 

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

[issue24058] Compiler warning for readline extension

[Roundup Robot]

Roundup Robot added the comment:

New changeset ec6ed10d611e by Benjamin Peterson in branch '3.4':
remove extern definition, since it's in a header file (closes #24058)
https://hg.python.org/cpython/rev/ec6ed10d611e

New changeset 192f9efe4a38 by Benjamin Peterson in branch '2.7':
remove extern definition, since it's in a header file (closes #24058)
https://hg.python.org/cpython/rev/192f9efe4a38

New changeset cb4334ab8453 by Benjamin Peterson in branch 'default':
merge 3.4 (#24058)
https://hg.python.org/cpython/rev/cb4334ab8453

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue24058] Compiler warning for readline extension

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

I tried another two case changing variable declaration.
First case of just removing "extern", Compiler similarly warns, and test passed.
Second case of removing "_PyOS_ReadlineTState" declaration, Compiler has not 
warned, and test passed.

First:
$ hg diff
diff -r a50707a73d84 Modules/readline.c
--- a/Modules/readline.cWed Nov 05 15:11:34 2014 +0100
+++ b/Modules/readline.cMon Apr 27 03:09:06 2015 +0900
@@ -1062,7 +1062,7 @@
 rl_callback_handler_remove();
 }
 
-extern PyThreadState* _PyOS_ReadlineTState;
+PyThreadState* _PyOS_ReadlineTState;
 
 static char *
 readline_until_enter_or_signal(const char *prompt, int *signal)

$ ./configure --prefix=/opt/py34 && make
...
building 'readline' extension
...
/cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.c:1065:16: 
warning: '_PyOS_ReadlineTState' redeclared without dllimport attribute: 
previous dllimport ignored [-Wattributes]
 PyThreadState* _PyOS_ReadlineTState;
^
...

$ make install
$ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline
== CPython 3.4.3+ (3.4:a50707a73d84+, Apr 27 2015, 02:59:04) [GCC 4.9.2]
==   CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian
==   hash algorithm: siphash24 32bit
==   /tmp/test_python_3872
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, 
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_readline
testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok
test_init (test.test_readline.TestReadline) ... ok

--
Ran 2 tests in 0.203s

OK
1 test OK.


Second:
$ hg diff
diff -r a50707a73d84 Modules/readline.c
--- a/Modules/readline.cWed Nov 05 15:11:34 2014 +0100
+++ b/Modules/readline.cMon Apr 27 04:13:45 2015 +0900
@@ -1062,7 +1062,6 @@
 rl_callback_handler_remove();
 }

-extern PyThreadState* _PyOS_ReadlineTState;

 static char *
 readline_until_enter_or_signal(const char *prompt, int *signal)

$ ./configure --prefix=/opt/py34 && make
... building 'readline' extension has not warned.

$ make install
$ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline
== CPython 3.4.3+ (3.4:a50707a73d84+, Apr 27 2015, 04:19:36) [GCC 4.9.2]
==   CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian
==   hash algorithm: siphash24 32bit
==   /tmp/test_python_5936
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, 
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_readline
testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok
test_init (test.test_readline.TestReadline) ... ok

--
Ran 2 tests in 0.160s

OK
1 test OK.

--

___
Python tracker 

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

[issue24063] Support Mageia and Arch Linux in the platform module

[Rémi Verschelde]

New submission from Rémi Verschelde:

Support for Mageia and Arch Linux was added in the platform module for Python 
3.x [1, 2], but the fix was not backported to the 2.7.x branch.

It would be nice to see these fixes cherry-picked for the incoming 2.7.10 
release.

[1] https://hg.python.org/cpython/rev/97a098aa4205
[2] https://hg.python.org/cpython/rev/85d827cbabfa

--
components: Library (Lib)
messages: 242073
nosy: akien
priority: normal
severity: normal
status: open
title: Support Mageia and Arch Linux in the platform module
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

[issue24018] add a Generator ABC

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think the throw() method should be required.
If you don't need throw(), send() or close(), then you aren't really asking for 
a full-blown generator: you are asking for an iterator, so you can just check 
for collections.Iterator.

(PS: why is this bug assigned to Lukasz?)

--

___
Python tracker 

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

[issue24018] add a Generator ABC

[Raymond Hettinger]

Raymond Hettinger added the comment:

In the lastest patch, the close() method is now a valid mixin method.  

However, the throw() method should be made abstract because it doesn't provide 
the required operation (it doesn't even use the "self" argument) or it should 
be left out entirely (i.e. Numba only supporting next()) if the presence of 
throw() is not required.

Going back to Stefan's original use case, the problem being solved is that 
isinstance(g, types.GeneratorType) rejects regular classes that implement 
send(), next(), throw(), and close(), presumably because it is going to call 
those methods and expect that they work.

If an object tests positive for isinstance(g, collections.abc.Generator), what 
can we then assume about the object.  It would be weird to pass that test, see 
a throw() method, call it and have it do something other than raise an 
exception inside the generator.

g = lazy_readline_from_connection('171.0.0.1')
if isinstance(g, collections.abc.Generator):
# We passed the isinstance check, now what does that
# actually mean?  What is guaranteed to work?
next(g)
g.close()# Expect this to close the connection


If a working throw() isn't actually required, then the code ought to be 
checking for isinstance(obj, collections.abc.Iterator) or somesuch; otherwise, 
was is the point of doing any checks for a generator-like object?

I don't think this patch should go in until it is capable of doing something 
meaningful.  Otherwise, it looks like at attempt to bluff its way past 
generator checks that were presumably there for a reason.

--

___
Python tracker 

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

[issue24062] links to os.stat() in documentation lead to stat module instead

[July Tikhonov]

New submission from July Tikhonov:

Documentation of os.fstat()
https://docs.python.org/3/library/os.html#os.fstat
has a "See also:" section, which features a wrong link. The same with 
os.lstat().

Some of this problem was fixed (among other things) in issue 10960. But since 
then, two more wrong links appeared.

Attached patch applies to 3.5, although 3.4 has the same problem.

--
assignee: docs@python
components: Documentation
files: doc-library-os-stat-links.diff
keywords: patch
messages: 242070
nosy: docs@python, july
priority: normal
severity: normal
status: open
title: links to os.stat() in documentation lead to stat module instead
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39209/doc-library-os-stat-links.diff

___
Python tracker 

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

[issue5784] raw deflate format and zlib module

[paul rubin]

paul rubin added the comment:

Hey, thanks for updating this.  I still remember the nasty incident that got me 
filing this report in the first place.  I'll look at the patch more closely 
when I get a chance, but the immediate comment I'd make is it's worth adding a 
sentence saying explicitly to use wbits=-15 if you need to interoperate with 
some other libraries like PHP, that strip off the header.

--

___
Python tracker 

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

[issue22544] Inconsistent cmath.log behaviour

[Mark Dickinson]

Mark Dickinson added the comment:

Per: yes, that's true. I don't think changing either division or multiplication 
is the way forward for this issue, though; I'd rather implement the less 
invasive change where `cmath.log` special-cases the situation where its second 
argument is real and positive.

--

___
Python tracker 

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

[issue24059] Minor speed and readability improvement to the random module

[Tim Peters]

Tim Peters added the comment:

Good catch, Mark!

--

___
Python tracker 

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

[issue24059] Minor speed and readability improvement to the random module

[Mark Dickinson]

Mark Dickinson added the comment:

Ah, I missed that the issue was already closed.  Apologies for the excitement 
and the gratuitous exclamation marks in my previous messages.

--

___
Python tracker 

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

[issue24059] Minor speed and readability improvement to the random module

[Mark Dickinson]

Mark Dickinson added the comment:

Timing results on my machine:

(Canopy 64bit) taniyama:~ mdickinson$ python3 -m timeit -s "from math import 
sqrt; x = 3.14" "sqrt(x)"
1000 loops, best of 3: 0.0426 usec per loop
(Canopy 64bit) taniyama:~ mdickinson$ python3 -m timeit -s "from math import 
sqrt; x = 3.14" "x**0.5"
1000 loops, best of 3: 0.0673 usec per loop

And the disassembly showing the peephole optimizer at work:

>>> def f(): return 3.14**0.5
... 
>>> import dis
>>> dis.dis(f)
  1   0 LOAD_CONST   3 (1.772004514666935)
  3 RETURN_VALUE

--

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Yury Selivanov]

Yury Selivanov added the comment:

> Could we have type slots for the new special methods? Otherwise, implementing 
> the protocol in C would be fairly inefficient, especially for async iteration.

I don't think it's necessary to have slots for __aiter__, __anext__, __aenter__ 
and __aexit__.  Async iteration will never be as fast as regular iteration, and 
there is plenty overhead in it.  And we don't need slots for async context 
managers as we don't have slots for regular ones.

What might be a good idea is to add a slot for __await__ method -- tp_await.  
This will allow to implement Futures in C efficiently.  I'd rename 
'tp_reserved' for this purpose.

Victor, your thoughts?

--

___
Python tracker 

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

[issue24059] Minor speed and readability improvement to the random module

[Mark Dickinson]

Mark Dickinson added the comment:

Gah!  Peephole optimizer!  When you do a timeit for '3.14 ** 0.5', you're just 
evaluating the time to retrieve a constant!

In general, `**` is going to be both slower *and* less accurate than math.sqrt. 
 Please don't make this change!

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Cyd Haselton]

Cyd Haselton added the comment:

On a related note, I managed to get pip working with this build...minus some 
errors with verbose mode.  I first had to make some edits to setup.py and 
Modules/Setup so that the build would find and make the _ssl and lzip modules. 
After running make install, I ran 'python -m ensurepip'. I tested it by 
searching for and installing the BeautifulSoup module.

Ryan,
Let me know what are the next steps for this issue/build...and I'll do my best 
to get them done.

--

___
Python tracker 

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

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

[Antoine Pitrou]

Antoine Pitrou added the comment:

Those should be in the os module, not in sys. The os module is for interfaces 
to the operating system, while the sys module is for Python-specific stuff.

As for the point of adding them, I don't find them useful, but I won't oppose 
it either :-)

--
nosy: +pitrou

___
Python tracker 

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

[Antoine Pitrou]

Antoine Pitrou added the comment:

Thanks for the patch!

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.3

___
Python tracker 

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

[Roundup Robot]

Roundup Robot added the comment:

New changeset 15c80f63ea1c by Antoine Pitrou in branch '3.4':
Issue #23996: Avoid a crash when a delegated generator raises an unnormalized 
StopIteration exception.  Patch by Stefan Behnel.
https://hg.python.org/cpython/rev/15c80f63ea1c

New changeset 9d0c6c66b0ac by Antoine Pitrou in branch 'default':
Issue #23996: Avoid a crash when a delegated generator raises an unnormalized 
StopIteration exception.  Patch by Stefan Behnel.
https://hg.python.org/cpython/rev/9d0c6c66b0ac

--
nosy: +python-dev

___
Python tracker 

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

[issue24058] Compiler warning for readline extension

[Benjamin Peterson]

Benjamin Peterson added the comment:

Does simply removing the "extern" work?

--

___
Python tracker 

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

[issue24059] Minor speed and readability improvement to the random module

[Raymond Hettinger]

Raymond Hettinger added the comment:

Okay, I give up.

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

[issue13567] HTTPError interface changes / breaks depending on what was passed to constructor

[Demian Brecht]

Changes by Demian Brecht :


--
nosy: +demian.brecht

___
Python tracker 

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

[Stefan Behnel]

Stefan Behnel added the comment:

Could we have type slots for the new special methods? Otherwise, implementing 
the protocol in C would be fairly inefficient, especially for async iteration.

I'm asking because Cython's generator type is not Python's generator type, but 
implementing the rest of the proposed protocol doesn't seem to be all that 
difficult.

--

___
Python tracker 

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

[issue24061] Python 2.x breaks with address sanitizer

[Hanno Boeck]

Changes by Hanno Boeck :


--
type:  -> enhancement

___
Python tracker 

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

[issue24061] Python 2.x breaks with address sanitizer

[Hanno Boeck]

New submission from Hanno Boeck:

Right now it is not possible to build python 2.7.9 with address sanitizer. This 
issue has been worked around for python 3 in bug #18596 by marking some 
functions with attributes to tell address sanitizer to ignore them.

I have attached a patch that will apply the same workaround to python 2.7. I'd 
apprechiate if this could be applied before the next python 2 release. Although 
it's the "old" python 2 version I think this is important enough to be 
backported.

--
files: python-2.7.9-workaround-asan.diff
keywords: patch
messages: 242055
nosy: hanno
priority: normal
severity: normal
status: open
title: Python 2.x breaks with address sanitizer
versions: Python 2.7
Added file: http://bugs.python.org/file39208/python-2.7.9-workaround-asan.diff

___
Python tracker 

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

[issue24018] add a Generator ABC

[Ludovic Gasc]

Ludovic Gasc added the comment:

Sorry guys to be basic for you, but if I take my "AsyncIO end-user" hat, I'm 
not sure to understand the potential end-user source code impacts to use Cython 
with Python 3.5 and AsyncIO.

In concrete terms, it's only a low-level change, Cython will monkeypatch 
CPython if it's missing. I can continue to use asyncio.iscoroutine() function 
to detect coroutines.
Or it should be better to change something in AsyncIO libs and/or end-user 
source code ?

With the potential async/await inclusion in Python 3.5, it should be good to 
know if something else is necessary to help for the Cython support.

--
nosy: +Ludovic.Gasc

___
Python tracker 

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

[issue23852] Wrong computation of max_fd on OpenBSD

[Berker Peksag]

Changes by Berker Peksag :


--
stage: patch review -> resolved

___
Python tracker 

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

[issue24021] Add docstring to urllib.urlretrieve

[Berker Peksag]

Changes by Berker Peksag :


--
keywords: +easy
stage:  -> needs patch
title: document urllib.urlretrieve -> Add docstring to urllib.urlretrieve
type:  -> enhancement
versions: +Python 3.4, Python 3.5

___
Python tracker 

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

[issue23356] In argparse docs simplify example about argline

[Berker Peksag]

Berker Peksag added the comment:

Thanks py.user.

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

[issue23356] In argparse docs simplify example about argline

[Roundup Robot]

Roundup Robot added the comment:

New changeset 050e0c0b3d90 by Berker Peksag in branch '2.7':
Issue #23356: Simplify convert_arg_line_to_args example.
https://hg.python.org/cpython/rev/050e0c0b3d90

--

___
Python tracker 

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

[issue23356] In argparse docs simplify example about argline

[Roundup Robot]

Roundup Robot added the comment:

New changeset bd8b99034121 by Berker Peksag in branch '3.4':
Issue #23356: Simplify convert_arg_line_to_args example.
https://hg.python.org/cpython/rev/bd8b99034121

New changeset 2d3ed019bc9f by Berker Peksag in branch 'default':
Issue #23356: Simplify convert_arg_line_to_args example.
https://hg.python.org/cpython/rev/2d3ed019bc9f

--
nosy: +python-dev

___
Python tracker 

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

[issue22881] show median in benchmark results

[Stefan Behnel]

Stefan Behnel added the comment:

Any more comments on the patch, or can it be applied?

--

___
Python tracker 

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

[issue23342] run() - unified high-level interface for subprocess

[Berker Peksag]

Changes by Berker Peksag :


--
stage: commit review -> resolved

___
Python tracker 

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

[issue9951] introduce bytes.hex method (also for bytearray and memoryview)

[Berker Peksag]

Changes by Berker Peksag :


--
stage: commit review -> resolved

___
Python tracker 

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

[Stefan Behnel]

Changes by Stefan Behnel :


--
nosy: +pitrou

___
Python tracker 

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

[issue20485] Enable non-ASCII extension module names

[Stefan Behnel]

Stefan Behnel added the comment:

PEP 489 (Redesigning extension module loading) includes the proposal to fix 
this by using punycode.

--

___
Python tracker 

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

[issue22486] Add math.gcd()

[Stefan Behnel]

Stefan Behnel added the comment:

Any more comments on this? The deadlines for new features in Py3.5 are getting 
closer. It seems we're just discussing details here, but pretty much everyone 
wants this feature.

So, what are the things that still need to be done? Serhiy submitted working 
patches months ago.

--

___
Python tracker 

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