Mailman 3 June 2012 - Python-Dev

Add os.path.resolve to simplify the use of os.readlink
by Armin Ronacher 21 Jun '12

21 Jun '12

Due to an user error on my part I was not using os.readlink correctly. Since links can be relative to their location I think it would make sense to provide an os.path.resolve helper that automatically returns the absolute path: def resolve(filename): try: target = os.readlink(filename) except OSError as e: if e.errno == errno.EINVAL: return abspath(filename) raise return normpath(join(dirname(filename), target)) The above implementation also does not fail if an entity exists but is not a link and just returns the absolute path of the given filename in that case. Regards, Armin

6 11

Fwd: Re: Add os.path.resolve to simplify the use of os.readlink
by Calvin Spealman 21 Jun '12

21 Jun '12

---------- Forwarded message ---------- (whoops from my phone) On Jun 21, 2012 6:32 AM, "Armin Ronacher" <armin.ronacher(a)active-4.com> wrote: > > Due to an user error on my part I was not using os.readlink correctly. > Since links can be relative to their location I think it would make sense > to provide an os.path.resolve helper that automatically returns the > absolute path: > > def resolve(filename): > try: > target = os.readlink(filename) > except OSError as e: > if e.errno == errno.EINVAL: > return abspath(filename) > raise > return normpath(join(dirname(filename), target)) > > The above implementation also does not fail if an entity exists but is not > a link and just returns the absolute path of the given filename in that > case. > Does it need to be an absolute path, and what if the advantage of that? Can it returned absolute if that's what you gave it, and relative otherwise? > > Regards, > Armin > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com

1 0

Cannot find the main Python library during installing some app.
by Van Gao 21 Jun '12

21 Jun '12

hi, I got the error below during installing the libmobiledevice: checking consistency of all components of *python development environment... no* configure: error: Could not link test program to Python. Maybe the main Python library has been installed in some non-standard library path. If so, pass it to configure, via the LDFLAGS environment variable. Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib" ============================================================================ ERROR! You probably have to install the development version of the Python package for your distribution. The exact name of this package varies among them. ============================================================================ I have installed the python2.7, but I cannot find the lib under the /usr/local/lib/python2.7, *so where can I get the development version for python*? I downloaded the Python-2.7.3.tgz from python.org, is there any different between the development version with the tgz file? Thanks. -- View this message in context: http://python.6.n6.nabble.com/Cannot-find-the-main-Python-library-during-in… Sent from the Python - python-dev mailing list archive at Nabble.com.

3 2

Packaging documentation and packaging.pypi API
by Paul Moore 20 Jun '12

20 Jun '12

On 20 June 2012 14:47, Paul Moore <p.f.moore(a)gmail.com> wrote: > On 20 June 2012 14:16, Alexis Métaireau <alexis(a)notmyidea.org> wrote: >> packaging.pypi is functionally working but IMO the API can (and probably >> should) be improved (we really lack feedback to know that). > > I wasn't aware of this - I've had a look and my first thought is that > the documentation needs completing. At the moment, there's a lot that > isn't documented, and we should avoid getting into the same situation > as with distutils where people have to use undocumented APIs to get > anything done. There are a lot of examples, but not so much formal API > documentation. As a specific example, one thing I would like to do is to be able to set up a packaging.pypi client object that lets me query and download distributions. However, rather than just querying PyPI (the default) I'd like to be able to set up a list of locations (PyPI, a local server, and maybe some distribution files stored on my PC) and combine results from all of them. This differs from the mirror support in that I want to combine the lists, not use one as a fallback if the other doesn't exist. From the documentation, I can't tell if this is possible, or a feature request, or unsupported... (Actually, there's not even any documentation saying how the URL(s) in index_url should behave, so how exactly do I set up a local repository anyway...?) On a similar note, at some point, crawler.get_releases('pywin32') needs to work. I believe the issue here is technically with pywin32, which uses non-standard version numbers (214) and is hosted externally (Sourceforge) but I'd expect that packaging.pypi should be able to access anything that's on PyPI, even if other APIs like packaging.version can't deal with them. Ideally, these would be simply things I'd raise as issues on bugs.python.org. But as things stand, such issues aren't getting fixed, and we don't move forward. And without the documentation to back up a debate, it's hard to argue "X is a bug, Y is a feature request, Z is behaving correctly". Paul. PS As I write this, it suggests to me that maybe even the "pick out the stable APIs" approach isn't as simple as we'd like to think it is. You can either read this email as a set of specific documentation points to fix, or as evidence that we should drop packaging.pypi as well for now, even though it's a pretty cool feature...

3 6

Re: [Python-Dev] cpython: Prefer assertEqual to simply assert per recommendation in issue6727.
by Georg Brandl 20 Jun '12

20 Jun '12

Am 20.06.2012 16:25, schrieb jason.coombs: > http://hg.python.org/cpython/rev/24369f6c4a22 > changeset: 77525:24369f6c4a22 > user: Jason R. Coombs <jaraco(a)jaraco.com> > date: Wed Jun 20 10:24:24 2012 -0400 > summary: > Prefer assertEqual to simply assert per recommendation in issue6727. > Clarified comment on disabled code to reference issue15093. > > files: > Lib/test/test_import.py | 11 ++++++++--- > 1 files changed, 8 insertions(+), 3 deletions(-) > > > diff --git a/Lib/test/test_import.py b/Lib/test/test_import.py > --- a/Lib/test/test_import.py > +++ b/Lib/test/test_import.py > @@ -707,14 +707,19 @@ > os.mkdir(self.tagged) > init_file = os.path.join(self.tagged, '__init__.py') > open(init_file, 'w').close() > - assert os.path.exists(init_file) > + self.assertEqual(os.path.exists(init_file), True) > > # now create a symlink to the tagged package > # sample -> sample-tagged > os.symlink(self.tagged, self.package_name) > > - # assert os.path.isdir(self.package_name) # currently fails > - assert os.path.isfile(os.path.join(self.package_name, '__init__.py')) > + # disabled because os.isdir currently fails (see issue 15093) > + # self.assertEqual(os.path.isdir(self.package_name), True) > + > + self.assertEqual( > + os.path.isfile(os.path.join(self.package_name, '__init__.py')), > + True, > + ) Actually, in this case self.assertTrue() is the correct method. cheers, Georg

1 0

PEP 362 minor nits
by Jim Jewett 20 Jun '12

20 Jun '12

I've limited this to minor issues, but kept python-dev in the loop because some are questions, rather than merely editorial. Based on: http://hg.python.org/peps/file/tip/pep-0362.txt view pep-0362.txt @ 4466:659639095ace Committing the latest changes to PEP 362 on behalf of Yury Selivanov. author Larry Hastings <larry(a)hastings.org> date Tue, 19 Jun 2012 02:38:15 -0700 (3 hours ago) parents c1f693b39292 ================== 44 * return_annotation : object 45 The annotation for the return type of the function if specified. 46 If the function has no annotation for its return type, this 47 attribute is not set. I don't think you need the "if specified", given the next line. Similar comments around line 89 (Parameter.default) and 93 (Parameter.annotation). 48 * parameters : OrderedDict 49 An ordered mapping of parameters' names to the corresponding 50 Parameter objects (keyword-only arguments are in the same order 51 as listed in ``code.co_varnames``). Are you really sure you want to promise the keyword-only order in the PEP? [BoundArguments] 139 * arguments : OrderedDict 140 An ordered, mutable mapping of parameters' names to arguments' values. 141 Does not contain arguments' default values. I think 141 should be reworded, but I'm not certain my wording doesn't have similar problems, so I merely offer it: arguments contains only explicitly bound parameters; parameters for which the binding relied on a default value do not appear in arguments. 142 * args : tuple 143 Tuple of positional arguments values. Dynamically computed from 144 the 'arguments' attribute. 145 * kwargs : dict 146 Dict of keyword arguments values. Dynamically computed from 147 the 'arguments' attribute. Do you want to specify which will contain the normal parameters, that could be called either way? My naive assumption would be that as much as possible gets shoved into args, but once a positional parameter is left to default, remaining parameters are stuck in kwargs. 172 - If the object is not callable - raise a TypeError 173 174 - If the object has a ``__signature__`` attribute and if it 175 is not ``None`` - return a shallow copy of it Should these two be reversed? 183 - If the object is a method or a classmethod, construct and return 184 a new ``Signature`` object, with its first parameter (usually 185 ``self`` or ``cls``) removed 187 - If the object is a staticmethod, construct and return 188 a new ``Signature`` object I would reverse these two, to make it clear that a staticmethod is not treated as a method. 194 - If the object is a class or metaclass: 195 196 - If the object's type has a ``__call__`` method defined in 197 its MRO, return a Signature for it 198 199 - If the object has a ``__new__`` method defined in its class, 200 return a Signature object for it 201 202 - If the object has a ``__init__`` method defined in its class, 203 return a Signature object for it What happens if it inherits a __new__ or __init__ from something more derived than object? 207 Note, that I would remove the comma. 235 Some functions may not be introspectable 236 ---------------------------------------- 237 238 Some functions may not be introspectable in certain implementations of 239 Python. For example, in CPython, builtin functions defined in C provide 240 no metadata about their arguments. Adding support for them is out of 241 scope for this PEP. Ideally, it would at least be possible to manually construct a signature, and register them in some central location. (Similar to what is done with pickle or copy.) Checking that location would then have to be an early step in the signature algorithm. -jJ

5 9

Raw string syntax inconsistency
by Christian Heimes 20 Jun '12

20 Jun '12

Hello, the topic came up on the python-users list today. The raw string syntax has a minor inconsistency. The ru"" notation is a syntax error although we support rb"". Neither rb"" nor ru"" are supported on Python 2.7. Python 3.3: works: r"", ur"", br"", rb"" syntax error: ru"" Python 2.7: works: r"", ur"", br"" syntax error: ru"", rb"" The ru"" notation isn't necessary for Python 2 compatibility but it's still an inconsistency. The docs [1] also state that 'r' is a prefix, not a suffix. On the other hand the lexical definition doesn't mention the u"" notation yet. Christian [1] http://docs.python.org/py3k/reference/lexical_analysis.html#string-and-byte…

7 20

pep 362 - 5th edition
by Yury Selivanov 20 Jun '12

20 Jun '12

Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ Summary: 1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'. __copy__ creates a shallow copy of Signature, shallow copying its Parameters as well. 2. 'Signature.format()' was removed. I think we'll add something to customize formatting later, in 3.4. Although, Signature still has its __str__ method. 3. Built-in ('C') functions no longer have mutable '__signature__' attribute, that patch was reverted. In the "Design Considerations" section we stated clear that we don't support some callables. 4. Positions of keyword-only parameters now longer affect equality testing of Signatures, i.e. 'foo(*, a, b)' is equal to 'foo(*, b, a)' (Thanks to Jim Jewett for pointing that out) The only question we have now is: when we do equality test between Signatures, should we account for positional-only, var_positional and var_keyword arguments names? So that: 'foo(*args)' will be equal to 'bar(*arguments)', but not to 'spam(*coordinates:int)' (Again, I think that's a Jim's idea) Thank you! -- PEP: 362 Title: Function Signature Object Version: $Revision$ Last-Modified: $Date$ Author: Brett Cannon <brett(a)python.org>, Jiwon Seo <seojiwon(a)gmail.com>, Yury Selivanov <yselivanov(a)sprymix.com>, Larry Hastings <larry(a)hastings.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 21-Aug-2006 Python-Version: 3.3 Post-History: 04-Jun-2012 Abstract ======== Python has always supported powerful introspection capabilities, including introspecting functions and methods (for the rest of this PEP, "function" refers to both functions and methods). By examining a function object you can fully reconstruct the function's signature. Unfortunately this information is stored in an inconvenient manner, and is spread across a half-dozen deeply nested attributes. This PEP proposes a new representation for function signatures. The new representation contains all necessary information about a function and its parameters, and makes introspection easy and straightforward. However, this object does not replace the existing function metadata, which is used by Python itself to execute those functions. The new metadata object is intended solely to make function introspection easier for Python programmers. Signature Object ================ A Signature object represents the call signature of a function and its return annotation. For each parameter accepted by the function it stores a `Parameter object`_ in its ``parameters`` collection. A Signature object has the following public attributes and methods: * return_annotation : object The annotation for the return type of the function if specified. If the function has no annotation for its return type, this attribute is not set. * parameters : OrderedDict An ordered mapping of parameters' names to the corresponding Parameter objects (keyword-only arguments are in the same order as listed in ``code.co_varnames``). * bind(\*args, \*\*kwargs) -> BoundArguments Creates a mapping from positional and keyword arguments to parameters. Raises a ``TypeError`` if the passed arguments do not match the signature. * bind_partial(\*args, \*\*kwargs) -> BoundArguments Works the same way as ``bind()``, but allows the omission of some required arguments (mimics ``functools.partial`` behavior.) Raises a ``TypeError`` if the passed arguments do not match the signature. It's possible to test Signatures for equality. Two signatures are equal when their parameters are equal, their positional and positional-only parameters appear in the same order, and they have equal return annotations. Changes to the Signature object, or to any of its data members, do not affect the function itself. Signature also implements ``__str__`` and ``__copy__`` methods. The latter creates a shallow copy of Signature, with all Parameter objects copied as well. Parameter Object ================ Python's expressive syntax means functions can accept many different kinds of parameters with many subtle semantic differences. We propose a rich Parameter object designed to represent any possible function parameter. The structure of the Parameter object is: * name : str The name of the parameter as a string. * default : object The default value for the parameter, if specified. If the parameter has no default value, this attribute is not set. * annotation : object The annotation for the parameter if specified. If the parameter has no annotation, this attribute is not set. * kind : str Describes how argument values are bound to the parameter. Possible values: * ``Parameter.POSITIONAL_ONLY`` - value must be supplied as a positional argument. Python has no explicit syntax for defining positional-only parameters, but many builtin and extension module functions (especially those that accept only one or two parameters) accept them. * ``Parameter.POSITIONAL_OR_KEYWORD`` - value may be supplied as either a keyword or positional argument (this is the standard binding behaviour for functions implemented in Python.) * ``Parameter.KEYWORD_ONLY`` - value must be supplied as a keyword argument. Keyword only parameters are those which appear after a "*" or "\*args" entry in a Python function definition. * ``Parameter.VAR_POSITIONAL`` - a tuple of positional arguments that aren't bound to any other parameter. This corresponds to a "\*args" parameter in a Python function definition. * ``Parameter.VAR_KEYWORD`` - a dict of keyword arguments that aren't bound to any other parameter. This corresponds to a "\*\*kwds" parameter in a Python function definition. Two parameters are equal when they have equal names, kinds, defaults, and annotations. BoundArguments Object ===================== Result of a ``Signature.bind`` call. Holds the mapping of arguments to the function's parameters. Has the following public attributes: * arguments : OrderedDict An ordered, mutable mapping of parameters' names to arguments' values. Does not contain arguments' default values. * args : tuple Tuple of positional arguments values. Dynamically computed from the 'arguments' attribute. * kwargs : dict Dict of keyword arguments values. Dynamically computed from the 'arguments' attribute. The ``arguments`` attribute should be used in conjunction with ``Signature.parameters`` for any arguments processing purposes. ``args`` and ``kwargs`` properties can be used to invoke functions: :: def test(a, *, b): ... sig = signature(test) ba = sig.bind(10, b=20) test(*ba.args, **ba.kwargs) Implementation ============== The implementation adds a new function ``signature()`` to the ``inspect`` module. The function is the preferred way of getting a ``Signature`` for a callable object. The function implements the following algorithm: - If the object is not callable - raise a TypeError - If the object has a ``__signature__`` attribute and if it is not ``None`` - return a shallow copy of it - If it has a ``__wrapped__`` attribute, return ``signature(object.__wrapped__)`` - If the object is a an instance of ``FunctionType`` construct and return a new ``Signature`` for it - If the object is a method or a classmethod, construct and return a new ``Signature`` object, with its first parameter (usually ``self`` or ``cls``) removed - If the object is a staticmethod, construct and return a new ``Signature`` object - If the object is an instance of ``functools.partial``, construct a new ``Signature`` from its ``partial.func`` attribute, and account for already bound ``partial.args`` and ``partial.kwargs`` - If the object is a class or metaclass: - If the object's type has a ``__call__`` method defined in its MRO, return a Signature for it - If the object has a ``__new__`` method defined in its class, return a Signature object for it - If the object has a ``__init__`` method defined in its class, return a Signature object for it - Return ``signature(object.__call__)`` Note, that the ``Signature`` object is created in a lazy manner, and is not automatically cached. If, however, the Signature object was explicitly cached by the user, ``signature()`` returns a new shallow copy of it on each invocation. An implementation for Python 3.3 can be found at [#impl]_. The python issue tracking the patch is [#issue]_. Design Considerations ===================== No implicit caching of Signature objects ---------------------------------------- The first PEP design had a provision for implicit caching of ``Signature`` objects in the ``inspect.signature()`` function. However, this has the following downsides: * If the ``Signature`` object is cached then any changes to the function it describes will not be reflected in it. However, If the caching is needed, it can be always done manually and explicitly * It is better to reserve the ``__signature__`` attribute for the cases when there is a need to explicitly set to a ``Signature`` object that is different from the actual one Some functions may not be introspectable ---------------------------------------- Some functions may not be introspectable in certain implementations of Python. For example, in CPython, builtin functions defined in C provide no metadata about their arguments. Adding support for them is out of scope for this PEP. Examples ======== Visualizing Callable Objects' Signature --------------------------------------- Let's define some classes and functions: :: from inspect import signature from functools import partial, wraps class FooMeta(type): def __new__(mcls, name, bases, dct, *, bar:bool=False): return super().__new__(mcls, name, bases, dct) def __init__(cls, name, bases, dct, **kwargs): return super().__init__(name, bases, dct) class Foo(metaclass=FooMeta): def __init__(self, spam:int=42): self.spam = spam def __call__(self, a, b, *, c) -> tuple: return a, b, c def shared_vars(*shared_args): """Decorator factory that defines shared variables that are passed to every invocation of the function""" def decorator(f): @wraps(f) def wrapper(*args, **kwds): full_args = shared_args + args return f(*full_args, **kwds) # Override signature sig = wrapper.__signature__ = signature(f) for __ in shared_args: sig.parameters.popitem(last=False) return wrapper return decorator @shared_vars({}) def example(_state, a, b, c): return _state, a, b, c def format_signature(obj): return str(signature(obj)) Now, in the python REPL: :: >>> format_signature(FooMeta) '(name, bases, dct, *, bar:bool=False)' >>> format_signature(Foo) '(spam:int=42)' >>> format_signature(Foo.__call__) '(self, a, b, *, c) -> tuple' >>> format_signature(Foo().__call__) '(a, b, *, c) -> tuple' >>> format_signature(partial(Foo().__call__, 1, c=3)) '(b, *, c=3) -> tuple' >>> format_signature(partial(partial(Foo().__call__, 1, c=3), 2, c=20)) '(*, c=20) -> tuple' >>> format_signature(example) '(a, b, c)' >>> format_signature(partial(example, 1, 2)) '(c)' >>> format_signature(partial(partial(example, 1, b=2), c=3)) '(b=2, c=3)' Annotation Checker ------------------ :: import inspect import functools def checktypes(func): '''Decorator to verify arguments and return types Example: >>> @checktypes ... def test(a:int, b:str) -> int: ... return int(a * b) >>> test(10, '1') 1111111111 >>> test(10, 1) Traceback (most recent call last): ... ValueError: foo: wrong type of 'b' argument, 'str' expected, got 'int' ''' sig = inspect.signature(func) types = {} for param in sig.parameters.values(): # Iterate through function's parameters and build the list of # arguments types try: type_ = param.annotation except AttributeError: continue else: if not inspect.isclass(type_): # Not a type, skip it continue types[param.name] = type_ # If the argument has a type specified, let's check that its # default value (if present) conforms with the type. try: default = param.default except AttributeError: continue else: if not isinstance(default, type_): raise ValueError("{func}: wrong type of a default value for {arg!r}". \ format(func=func.__qualname__, arg=param.name)) def check_type(sig, arg_name, arg_type, arg_value): # Internal function that encapsulates arguments type checking if not isinstance(arg_value, arg_type): raise ValueError("{func}: wrong type of {arg!r} argument, " \ "{exp!r} expected, got {got!r}". \ format(func=func.__qualname__, arg=arg_name, exp=arg_type.__name__, got=type(arg_value).__name__)) @functools.wraps(func) def wrapper(*args, **kwargs): # Let's bind the arguments ba = sig.bind(*args, **kwargs) for arg_name, arg in ba.arguments.items(): # And iterate through the bound arguments try: type_ = types[arg_name] except KeyError: continue else: # OK, we have a type for the argument, lets get the corresponding # parameter description from the signature object param = sig.parameters[arg_name] if param.kind == param.VAR_POSITIONAL: # If this parameter is a variable-argument parameter, # then we need to check each of its values for value in arg: check_type(sig, arg_name, type_, value) elif param.kind == param.VAR_KEYWORD: # If this parameter is a variable-keyword-argument parameter: for subname, value in arg.items(): check_type(sig, arg_name + ':' + subname, type_, value) else: # And, finally, if this parameter a regular one: check_type(sig, arg_name, type_, arg) result = func(*ba.args, **ba.kwargs) # The last bit - let's check that the result is correct try: return_type = sig.return_annotation except AttributeError: # Looks like we don't have any restriction on the return type pass else: if isinstance(return_type, type) and not isinstance(result, return_type): raise ValueError('{func}: wrong return type, {exp} expected, got {got}'. \ format(func=func.__qualname__, exp=return_type.__name__, got=type(result).__name__)) return result return wrapper References ========== .. [#impl] pep362 branch (https://bitbucket.org/1st1/cpython/overview) .. [#issue] issue 15008 (http://bugs.python.org/issue15008) Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

5 20

PEP 397 - Last Comments
by Brian Curtin 20 Jun '12

20 Jun '12

Martin approached me earlier and requested that I act as PEP czar for 397. I haven't been involved in the writing of the PEP and have been mostly observing from the outside, so I accepted and hope to get this wrapped up quickly and implemented in time for the beta. The PEP is pretty complete, but there are a few outstanding issues. On Mon, Jun 18, 2012 at 1:05 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > "Independent installations will always only overwrite newer versions of the > launcher with older versions." 'always only' is a bit awkward and the > sentence looks backwards to me. I would expect only overwriting older > versions with newer versions. Agreed, I would expect the same. I would think taking out the word "only" and then flipping newer and older in the sentence would correct it. On Mon, Jun 18, 2012 at 1:05 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > These seem contradictory: > > "The 32-bit distribution of Python will not install a 32-bit version of the > launcher on a 64-bit system." > > I presume this mean that it will install the 64-bit version and that there > will always be only one version of the launcher on the system. > > "On 64bit Windows with both 32bit and 64bit implementations of the same > (major.minor) Python version installed, the 64bit version will always be > preferred. This will be true for both 32bit and 64bit implementations of > the launcher - a 32bit launcher will prefer to execute a 64bit Python > installation of the specified version if available." > > This implies to me that the 32bit installation *will* install a 32bit > launcher and that there could be both versions of the launcher installed. I took that as covering an independently-installed launcher. You could always install your own 32-bit launcher, and it'd prefer to launch a binary matching the machine type. So yes, there could be multiple launchers installed for different machine types, and I'm not sure why we'd want to (or how we could) prevent people from installing them. You could have a 64-bit launcher available system-wide in your Windows folder, then you could have a 32-bit launcher running out of C:\Users\Terry for some purposes. Martin - is that correct? === Outside of Terry's concerns, I find the updated PEP almost ready to go as-is. Many of the updates were in line with what Martin and I briefly talked about at PyCon, and I believe some of them came out of previous PEP discussions on here, so I see nothing unexpected at this point. My only additional comment would be to have the "Configuration file" implementation details supplemented with a readable example of where the py.ini file should be placed. On my machine that is "C:\Users\brian\AppData\Local", rather than making people have to run that parameter through the listed function via pywin32.

3 4

Help to fix this bug http://bugs.python.org/issue15068
by gmspro 19 Jun '12

19 Jun '12

Hi, I'm working on this bug to fix it. http://bugs.python.org/issue15068 >>> from sys import stdin >>> str=stdin.read() hello hello world CTRL+D CTRL+D Can anyone tell me where is stdin.read() function defined? Or where is sys.stdin defined? Or which function is called for str=stdin.read() ? Thanks

4 3