[issue1065986] Fix pydoc crashing on unicode strings

[Akira Kitada]

Akira Kitada added the comment:

Updated the previous patch to test unicode strings in 
__{version,date,author,credits}__ don't crash.

--
Added file: http://bugs.python.org/file31832/issue1065986-3.patch

___
Python tracker 

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

[issue13963] dev guide has no mention of mechanics of patch review

[Akira Kitada]

Changes by Akira Kitada :


--
nosy: +akitada

___
Python tracker 

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

[issue19050] crash while writing to a closed file descriptor

[Tim Golden]

Tim Golden added the comment:

I can confirm that 2.7.2 hard-crashes as described on Windows. I'm not 
sure if I have the wherewithal to build 2.7 on this laptop to see if 
it's fixed in tip.

3.3 simply raises an IOError.

--

___
Python tracker 

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

[issue19050] crash while writing to a closed file descriptor

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
priority: normal -> high

___
Python tracker 

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

[issue1185124] pydoc doesn't find all module doc strings

[Akira Kitada]

Changes by Akira Kitada :


--
nosy: +akitada

___
Python tracker 

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

[issue19060] docs: note that subprocess doesn't replace os.exec*

[anatoly techtonik]

New submission from anatoly techtonik:

I always thought that subprocess is replacing all other methods of executing 
external programs from Python and it is a preferred way. Perhaps I was not 
attentive that people isolate:
  os.system
  os.spawn*
  os.popen*
and
  os.exec*

While subprocess replaces three first, it doesn't do this with the last one. 
The documentation should mention this in the header block. Proposed edit:

  ...
  replace several other, older modules and functions, such as:

 os.system
 os.spawn*
 os.popen*
 popen2.*
 commands.*

+ Note that it doesn't replace other ways of executing external
+ processes from Python, such as:
+
+os.exec*

  Information about how the subprocess module can be used
  ...

--
assignee: docs@python
components: Documentation
messages: 198188
nosy: docs@python, techtonik
priority: normal
severity: normal
status: open
title: docs: note that subprocess doesn't replace os.exec*
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, 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

[issue19060] docs: note that subprocess doesn't replace os.exec*

[anatoly techtonik]

anatoly techtonik added the comment:

tag:easy (meaning, please mark it as easy for OpenHatch robots)

--

___
Python tracker 

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

[issue19056] Windows 7, script exec not working without explicit cal of python.exe

[Thierry Seunevel]

Thierry Seunevel added the comment:

Many thanks for your answers.
printing the sys.path gave me this output (parsed with newlines)
'', 'D:\\soft\\python\\lib', 
'D:\\Thierry\\python\\d\\thierry\\python', < mispelled
'C:\\Windows\\system32\\python27.zip',
'd:\\soft\\python\\DLLs', 
'd:\\soft\\python\\lib\\plat-win', 
'd:\\soft\\python\\lib\\lib-tk', 
'd:\\soft\\python', 
'd:\\soft\\python\\lib\\site-packages'

I corrected the PATH and PYTHONPATH environment variables and now sys.path is 
'', 'd:\\thierry\\python', 
'C:\\Windows\\system32\\python27.zip', 
'd:\\soft\\python\\DLLs', 
'd:\\soft\\python\\lib', 
'd:\\soft\\python\\lib\\plat-win', 
'd:\\soft\\python\\lib\\lib-tk', 
'd:\\soft\\python', 
'd:\\soft\\python\\lib\\site-packages'

And it works !

--
resolution:  -> fixed

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Changes by Marco Buttu :


Removed file: http://bugs.python.org/file31831/py3howto.patch

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Changes by Marco Buttu :


Removed file: http://bugs.python.org/file31830/py2howto.patch

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Marco Buttu added the comment:

I think the indentation is a problem, for several reasons. In all the examples 
in the documentation, the form by using the interactive shell is the following:

>>> class MyClass:
... pass

otherwise:

class MyClass:
pass

This one is awful:

>>> class MyClass:
pass

and in fact it is no used in the doc. So if you want to put the class clause in 
the interactive shell, you have to add the dots to indent the suite of the 
compound statement, in order to be consistent with the rest of all the 
documentation.
But it is not just a problem of beauty:

$ python -m doctest descriptor.rst 
**
File "descriptor.rst", line 165, in descriptor.rst
Failed example:
class MyClass(object):
Exception raised:
...
class MyClass(object):
 ^
SyntaxError: unexpected EOF while parsing
...

By applying the patch, the definitions of the classes RevealAccess and MyClass 
pass the documentation test. The whole example does not pass in any case, 
because you are not consistent using the shell notation.

--
Added file: http://bugs.python.org/file31833/py3howto.patch

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Changes by Marco Buttu :


--
resolution: invalid -> works for me
status: closed -> open

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Stefan Behnel]

Stefan Behnel added the comment:

Eli, seeing our discussion so far, ISTM that the parser-target interface is at 
the very heart of our disagreement.

For me, it's a good design that provides a clean separation of concerns between 
the parser that generates events, and the target (usually, but not necessarily 
a TreeBuilder) that processes them. The link back is then provided by the 
close() method (provided by both, BTW), which terminates the parsing process 
and passes the result through to the user. That result may be a tree, but 
that's completely up to the target, and whatever comes back is transparent to 
the parser (there's an example of that in the docs, BTW). That's a clean 
separation of concerns that I would like to copy in the design of the 
XMLPullParser (in fact, by inheriting from XMLParser). Extrapolating this exact 
design, whatever comes back from the callback methods should be transparent to 
the parser and should control the objects that the XMLPullParser collects for 
its events. I.e., it's the target's sole responsibility to convert the parser's 
calls into objects that make up both the collected events and the result ret
 urned by the parser's close() methods. Again, I consider this a very clean 
separation of concerns.

Essentially, I embrace the fact that the user is standing on both sides of the 
API and can control both the generation of the event objects (by providing a 
target object) and the processing of the events in front of the parser. To me, 
this is a very clean and extremely flexible design, and I hope it's clearer now 
why I consider it an excellent feature.

Now, several of your comments so far indicate an aversion towards the 
parser-target interface because it allows arbitrary objects to be returned by 
uncontrollable, user provided code, thus "tainting" the otherwise clean tree 
building interface of the new pull parser. On the other hand, you also stated 
that you would like to keep a separation between the parser and the TreeBuilder 
and do not want the parser to know about trees, so I guess that means that you 
also wouldn't want the parser to enforce any kind of tree building constraints 
on whatever the result of the parsing process is. As I said before, it's 
utterly unclear to me how both of these go together, but that's what I could 
extract from the discussion so far.

Would it be possible for you to clarify your own opinion on this topic, and, 
specifically, how you envision the role of the parser, the target and their 
separation of concerns during the event generation? I think this would help us 
get this discussion a little forward.

--

___
Python tracker 

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

[issue19056] Windows 7, script exec not working without explicit cal of python.exe

[Eric V. Smith]

Eric V. Smith added the comment:

Glad to see it's working.

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

[issue19061] Shelve documentation security warning is not visible

[anatoly techtonik]

New submission from anatoly techtonik:

This is a follow up to issue #8855. Currently the security warning is 
completely invisible from Python 2 docs 
http://docs.python.org/2/library/shelve.html and is located under screen border 
on Python 3 docs.

The proposal is to move warning out of the description of open() function to 
paragraph following module description, the same way is it is done for pickle 
http://docs.python.org/3.3/library/pickle.html

--
assignee: docs@python
components: Documentation
messages: 198194
nosy: docs@python, techtonik
priority: normal
severity: normal
status: open
title: Shelve documentation security warning is not visible
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, 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

[issue19061] Shelve documentation security warning is not visible

[anatoly techtonik]

anatoly techtonik added the comment:

tag:easy

--

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Nick Coghlan]

Nick Coghlan added the comment:

Actually, I think it's reasonable to define the custom target nominally
abstracted by PullParser as always returning None from close(). As Eli
notes, it's designed to let you discard events as you go, so remembering
them internally to return from close() doesn't make sense.

That means the patch could be simplified to just removing the root
attribute without changing the result of calling close().

--

___
Python tracker 

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

[issue10042] functools.total_ordering fails to handle NotImplemented correctly

[Nick Coghlan]

Nick Coghlan added the comment:

Raymond, do you still want to look at this one? Otherwise I'll finish it up
and commit it before the next alpha (I'll check the example in the enum
docs to see if it can be simplified, too).

--

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Marco Buttu added the comment:

By looking at the other examples in the howto, I saw there is the same problem 
in all the definitions in the prompt, and furthermore, we are using a different 
number of spaces to indent MyClass respect the rest of the classes defined in 
the prompt. 
There is also a wrong indentation in the StaticMethod definition (no prompt 
definition):

class StaticMethod(object):
 "Emulate PyStaticMethod_Type() in Objects/funcobject.c"

 def __init__(self, f):
  self.f = f

 def __get__(self, obj, objtype=None):
  return self.f

Applying the py3full.patch, the howto passes all the documentation tests:

$ python -m doctest descriptor.rst | tail -n 1
***Test Failed*** 18 failures.
$ python -m doctest descriptor_modified.rst | tail -n 1
$


My 2 cents

--
Added file: http://bugs.python.org/file31834/py3full.patch

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Stefan Behnel]

Stefan Behnel added the comment:

> That means the patch could be simplified to just removing the root
> attribute without changing the result of calling close().

Absolutely.

Returning the parse result from close() would still make it both more
consistent and easier to use (also from within iterparse()), but I agree
that that's more of a feature. If the goal is really just to get the bare
minimum API out that allows future extensions without introducing future
consistency issues, then I'm ok with that change, too.

However, note that the next lxml release will almost certainly have been
out for a while when Py3.4 finally lands (I'm currently planning the
release for next month, maybe early November), which means that the
complete, well integrated API, including target support for iterparse()
etc., will already have an established, publicly available implementation
when Py3.4 comes out. If ElementTree wants to have a word in the final
design of this feature, and wants to avoid introducing deliberate
incompatibilities in the future, then I'd prefer finishing up this
discussion before the next lxml release gets into beta state.

--

___
Python tracker 

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

[issue19054] Descriptors howto

[Ezio Melotti]

Ezio Melotti added the comment:

In the latest patch there are 5-spaces indents in several places.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue1065986] Fix pydoc crashing on unicode strings

[Akira Kitada]

Akira Kitada added the comment:

Now we have a working fix for 2.7.
Could someone please review the attached patch?

--

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Eli Bendersky]

Eli Bendersky added the comment:

On Sat, Sep 21, 2013 at 5:52 AM, Nick Coghlan wrote:

>
> Nick Coghlan added the comment:
>
> Actually, I think it's reasonable to define the custom target nominally
> abstracted by PullParser as always returning None from close(). As Eli
> notes, it's designed to let you discard events as you go, so remembering
> them internally to return from close() doesn't make sense.
>

IMHO the documentation is already sufficient w.r.t. this. By convention,
when a method does not return anything, we just don't mention its return
value. So:

  close()
  Signal the parser that the data stream is terminated.

Seems good.

> That means the patch could be simplified to just removing the root
> attribute without changing the result of calling close().
>

Unfortunately I don't have time to review refactoring patches now. In light
of a larger refactoring planned in this part of the module in the future, I
don't think it's very important to tweak things right now.

--

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Stefan Behnel]

Stefan Behnel added the comment:

> Unfortunately I don't have time to review refactoring patches now. In light 
> of a larger refactoring planned in this part of the module in the future, I 
> don't think it's very important to tweak things right now.

You misunderstood. The proposal was to remove the ".root" attribute, because it 
introduces a new API that hinders the future development and unnecessarily 
introduces an unprecedented inconsistency with existing APIs.

This is not a refactoring.

--

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Nick Coghlan]

Nick Coghlan added the comment:

Right, the minimum change needed is to prefix it with an underscore, but if
it isn't actually needed for anything, we may as well remove it entirely.

--

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Changes by Marco Buttu :


Removed file: http://bugs.python.org/file31834/py3full.patch

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Marco Buttu added the comment:

You are right. Now it should be ok

--
Added file: http://bugs.python.org/file31835/py3full.patch

___
Python tracker 

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

[issue19001] test_gdb fails on Fedora buildbot

[Stefan Krah]

Stefan Krah added the comment:

The regular build (with threads) on that machine has the same problem.

Closing the issue is fine, but there does not seem to be an easy way
to upgrade Fedora from 16 to 19. Perhaps we can skip the test so that
the buildbot continues to be useful.

--

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Marco Buttu added the comment:

By the way, it does not pass all the tests in Python 2.7:

$ python2.7 -m doctest descriptor_modified.rst | tail -n 1
***Test Failed*** 3 failures.

If we want to be very rigorous, in order to pass the tests in Py2.7 too 
(kipping the rst aligned between py2 and py3), we have to add 3 others doctest: 
+SKIP directives. 

PS. I think there is a small bug in sphinx, related to our examples:

https://bitbucket.org/birkenfeld/sphinx/issue/1271/doctest-directive-and-dots-not-hidden

--

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Eli Bendersky]

Eli Bendersky added the comment:

On Sat, Sep 21, 2013 at 7:26 AM, Nick Coghlan wrote:

>
> Nick Coghlan added the comment:
>
> Right, the minimum change needed is to prefix it with an underscore, but if
> it isn't actually needed for anything, we may as well remove it entirely.
>

Just to be clear - do we consider all non-prefixed-with-underscore
attributes of classes in the stdlib part of the public API, even when
they're explicitly undocumented? And while we're at it, all
non-prefixed-with-underscore methods as well?

I still consider this refactoring gratuitious at this point. The API is
well defined by the documentation. All the rest is implementation details.

--

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Stefan Behnel]

Stefan Behnel added the comment:

> I still consider this refactoring gratuitious at this point. The API is
> well defined by the documentation. All the rest is implementation details.

Famous last words.

--

___
Python tracker 

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

[issue19062] problems with pyshell to get userdir

[patrick wai]

New submission from patrick wai:

#file
idlelib/configHandler.py

#code
userDir = os.path.expanduser('~') 

#os
windows 7 sp1

it doesnt get final userdir path. it doesnt work correctly for userdir . 
this cause python3.3 IDLE GUI can not be opened on my pc . 
as per the docment says as follows:

help(os.path.expanduser)
Help on function expanduser in module ntpath:

expanduser(path)
Expand ~ and ~user constructs.

If user or $HOME is unknown, do nothing.

help(os.path.expandvars)
Help on function expandvars in module ntpath:

expandvars(path)
Expand shell variables of the forms $var, ${var} and %var%.

Unknown variables are left unchanged.

the right code may be:

userDir = os.path.expandvars(os.path.expanduser('~'))

--
components: IDLE
messages: 198210
nosy: weizhao
priority: normal
severity: normal
status: open
title: problems with pyshell to get userdir
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, 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

[issue19062] problems with pyshell to get userdir

[patrick wai]

patrick wai added the comment:

i am working under non-administrator account .
in fact os.path.expanduser('~') works well when as admin run .
but just got a %userprofile% when as standard account .

On Sat, Sep 21, 2013 at 11:39 PM, patrick wai wrote:

>
> New submission from patrick wai:
>
> #file
> idlelib/configHandler.py
>
> #code
> userDir = os.path.expanduser('~')
>
> #os
> windows 7 sp1
>
> it doesnt get final userdir path. it doesnt work correctly for userdir .
> this cause python3.3 IDLE GUI can not be opened on my pc .
> as per the docment says as follows:
>
> help(os.path.expanduser)
> Help on function expanduser in module ntpath:
>
> expanduser(path)
> Expand ~ and ~user constructs.
>
> If user or $HOME is unknown, do nothing.
>
> help(os.path.expandvars)
> Help on function expandvars in module ntpath:
>
> expandvars(path)
> Expand shell variables of the forms $var, ${var} and %var%.
>
> Unknown variables are left unchanged.
>
> the right code may be:
>
> userDir = os.path.expandvars(os.path.expanduser('~'))
>
> --
> components: IDLE
> messages: 198210
> nosy: weizhao
> priority: normal
> severity: normal
> status: open
> title: problems with pyshell to get userdir
> type: behavior
> versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4,
> Python 3.5
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue19009] Enhance HTTPResponse.readline() performance

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Ok, Here is a new patch.
We now inherit from BufferedIOBase.  We must implement read(amt) ourselves, 
since the base class does not do it.

I was wrong about the final chunk, it is in fact 0\r\n.  A final \r\n is then 
added to signal the end of the optional trailers.

Added a bunch of tests for chunked encoding, plus tests to verify http 
synchronization for keepalive connections.

--
Added file: http://bugs.python.org/file31836/httpresponse.patch

___
Python tracker 

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

[issue19054] Descriptors howto

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
status: open -> closed

___
Python tracker 

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

[issue14983] email.generator should always add newlines after closing boundaries

[Stephen J. Turnbull]

Stephen J. Turnbull added the comment:

Seems this hasn't been resolved.  I have to disagree with David's 
interpretation of RFC 2046.  The definition of a boundary says that it is 
"terminated" with a CRLF.  It also clarifies that the introducing CRLF is 
"conceptually part" of the boundary.  Thus each boundary contains both the 
leading and the trailing CRLF.  There is no exception for the final boundary 
that I can see.

This implies that when two boundaries abut, they need to be separated by *two* 
CRLFs, the trailing CRLF on the ending boundary of the inner multipart and the 
leading CRLF on the next boundary (which might be a separator or the ending 
boundary) of the containing multipart.

--
nosy: +sjt

___
Python tracker 

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

[issue14983] email.generator should always add newlines after closing boundaries

[Daniel Kahn Gillmor]

Daniel Kahn Gillmor added the comment:

I think the relevant specification for PGP/MIME-signed messages is RFC 3156:

 https://tools.ietf.org/html/rfc3156#page-5

in particular:

  Note: The accepted OpenPGP convention is for signed data to end
  with a  sequence.  Note that the  sequence
  immediately preceding a MIME boundary delimiter line is considered
  to be part of the delimiter in [3], 5.1.  Thus, it is not part of
  the signed data preceding the delimiter line.  An implementation
  which elects to adhere to the OpenPGP convention has to make sure
  it inserts a  pair on the last line of the data to be
  signed and transmitted (signed message and transmitted message
  MUST be identical).

--
nosy: +dkg

___
Python tracker 

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

[issue14983] email.generator should always add newlines after closing boundaries

[Stephen J. Turnbull]

Stephen J. Turnbull added the comment:

Following OpenPGP convention is clearly optional (or maybe a SHOULD, but the 
word "elect" makes it a pretty weak SHOULD).  RFC 2046 is a MUST, it's not a 
matter of "convention".

The problem is that a parser that works forward in the message will swallow the 
terminating CRLF of the boundary of the signed multipart, and then not find a 
CRLF to introduce the boundary that separates the content from the signature.  
By MIME rules it will treat the signature (including the unrecognized boundary) 
as an epilogue, and ignore it.  This is not at all special to multipart/signed.

--

___
Python tracker 

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

[issue14983] email.generator should always add newlines after closing boundaries

[R. David Murray]

R. David Murray added the comment:

Well, there are two problems here, I think (it's been a while since I looked at 
this): we should indeed be adding a crlf between mime boundary lines.  But also 
the clients should technically be handling it not being there, as well as the 
case of extra whitespace being added between the end of the delimiter and the 
following crlf (which I'm guessing they don't, since the logical way to handle 
that would be to ignore anything after the end of the delimiter string, in 
which case this problem wouldn't arise).

Specifically:

   The boundary may be followed by zero or more characters of linear
   whitespace. It is then terminated by either another CRLF...

and:

   NOTE TO IMPLEMENTORS:  Boundary string comparisons must compare the
   boundary value with the beginning of each candidate line.  An exact
   match of the entire candidate line is not required; it is sufficient
   that the boundary appear in its entirety following the CRLF.

So it seems to me that the PGP spec is not RFC conformant...but if we were 
following the RFC it wouldn't be an issue.

--

___
Python tracker 

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

[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

[Florian Apolloner]

New submission from Florian Apolloner:

Take the following example:

>>> from email.mime.nonmultipart import *
>>> from email.charset import *
>>> msg = MIMENonMultipart('text', 'plain')
>>> cs = Charset('utf-8')
>>> cs.body_encoding = None
>>> msg.set_payload('А Б В Г Д Е Ж Ѕ З И І К Л М Н О П.', cs)
>>> msg.as_string()
'MIME-Version: 1.0\nContent-Type: text/plain; 
charset="utf-8"\nContent-Transfer-Encoding: 7bit\n\nА Б В Г Д Е Ж Ѕ З И І К Л М 
Н О П.'

Till python 3.3.2 this created the email as 8bit, which is in line with what 
Thunderbird creates on my box. And if I understand the RFC correctly 
(https://tools.ietf.org/html/rfc2045#section-2.7) 7bit should only be used for 
ASCII. This issue was introduced by 
http://hg.python.org/cpython/rev/64e004737837 -- I changed orig = 
msg.get_payload(decode=True) back to it's original value (decode=False) in 
encode_7or8bit and get the "correct" behavior again. Running the tests didn't 
cause any errors (I hope I ran the correct one).

--
components: Library (Lib)
messages: 198217
nosy: apollo13
priority: normal
severity: normal
status: open
title: Python 3.3.3  encodes emails containing non-ascii data as 7bit
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

[issue14983] email.generator should always add newlines after closing boundaries

[R. David Murray]

R. David Murray added the comment:

Heh, rather than "not conformant" I should have said that the two RFCs are in 
conflict, in my opinion.

--

___
Python tracker 

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

[issue14983] email.generator should always add newlines after closing boundaries

[R. David Murray]

R. David Murray added the comment:

Stephen: my post crossed yours.  Yes, I agree with your logic, having re-read 
the spec (the trailing CR is clearly part of the boundary).  But I still think 
the logic of the signing/validation is an invitation for running into problems 
like this.

--

___
Python tracker 

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

[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

[R. David Murray]

R. David Murray added the comment:

There is definitely a bug here, but 8bit would also be wrong, since you are 
calling as_string.  It *should* be producing a 7bit CTE with a base64 encoded 
part in that case.

--
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.2, Python 3.4

___
Python tracker 

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

[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

[Florian Apolloner]

Florian Apolloner added the comment:

Am I not explicitelly disabling base64 by setting body_encoding to None?

--

___
Python tracker 

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

[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

[R. David Murray]

R. David Murray added the comment:

You are, but you are also calling as_string.  Unicode can not handle 8bit data, 
therefore the email package must down-transform all data to 7bit when 
converting it to a string, just like a mail server trying to send to another 
mail server that can only handle 7bit would do.

If you used BytesGenerator to serialize the message, *then* you would expect to 
see 8bit utf-8 data in the body.

There are supposed to be tests for these cases, so I have to investigate why 
the tests are broken, as well :)

--

___
Python tracker 

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

[issue19054] Descriptors howto

[Marco Buttu]

Marco Buttu added the comment:

$ python -c "import this" | grep "silently"
Errors should never pass silently

--

___
Python tracker 

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

[issue19064] can't run py3 benchmarks

[Antoine Pitrou]

New submission from Antoine Pitrou:

After the latest changes I don't understand how I'm supposed to run translated 
Python 3 benchmarks:

$ ./perf.py -fb mako_v2 ../opt/python ../x32opt/python 
Running mako_v2...
INFO:root:Running ../x32opt/python ./performance/bm_mako_v2.py -n 50
Traceback (most recent call last):
  File "./perf.py", line 2460, in 
main(sys.argv[1:])
  File "./perf.py", line 2416, in main
options)))
  File "./perf.py", line 1528, in BM_mako_v2
return SimpleBenchmark(MeasureMakoV2, *args, **kwargs)
  File "./perf.py", line 714, in SimpleBenchmark
*args, **kwargs)
  File "./perf.py", line 1524, in MeasureMakoV2
iteration_scaling=10)
  File "./perf.py", line 1113, in MeasureGeneric
inherit_env=options.inherit_env)
  File "./perf.py", line 1071, in CallAndCaptureOutput
raise RuntimeError("Benchmark died: " + stderr.decode('latin1'))
RuntimeError: Benchmark died: Traceback (most recent call last):
  File "./performance/bm_mako_v2.py", line 26, in 
from mako.template import Template
  File "/home/antoine/cpython/benchmarks/lib/Mako-0.7.3/mako/template.py", line 
622
exec code in module.__dict__, module.__dict__
^
SyntaxError: invalid syntax

--
assignee: brett.cannon
components: Benchmarks
messages: 198224
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: can't run py3 benchmarks
versions: 3rd party

___
Python tracker 

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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[Terry J. Reedy]

Terry J. Reedy added the comment:

A class attribute is still a special case fix to a generic problem, if indeed 
the message is a problem.

If class attribute backup is to become a requirement of all delete methods, it 
needs to first be documented, after pydev discussion. To apply the class 
attribute fix generally is tricky. If one does not create a class attribute 
backup for every attribute referenced in __del__, one must analyze the __init__ 
method for all points of possible failure, to see which attributes referenced 
in __del__ might be missing. Changing __init__ might change the analysis. This 
looks like a bad path to me.

The whole point of the special case ignoring of AttributeError in __delete__ 
methods is that AttributeErrors are *expected* in certain circumstances.

I opened a thread on pydev to discuss this issue.
"Revert #12085 fix for __del__ attribute error message"

The OP can avoid this issue entirely by using a conditional
  if sys.version_info < (3, 2, 0)
I consider this better code than intentionally creating an uninitialized 
instance.

--

___
Python tracker 

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

[issue1065986] Fix pydoc crashing on unicode strings

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
stage:  -> patch review

___
Python tracker 

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

[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

[Florian Apolloner]

Florian Apolloner added the comment:

Using BytesGenerator I get:
>>> fp = BytesIO()
>>> g = BytesGenerator(fp)
>>> msg = MIMENonMultipart('text', 'plain')
>>> msg.set_payload('А Б В Г Д Е Ж Ѕ З И І К Л М Н О П.', cs)
>>> g.flatten(msg)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.3/email/generator.py", line 112, in flatten
self._write(msg)
  File "/usr/lib/python3.3/email/generator.py", line 177, in _write
self._dispatch(msg)
  File "/usr/lib/python3.3/email/generator.py", line 203, in _dispatch
meth(msg)
  File "/usr/lib/python3.3/email/generator.py", line 421, in _handle_text
super(BytesGenerator,self)._handle_text(msg)
  File "/usr/lib/python3.3/email/generator.py", line 233, in _handle_text
self._write_lines(payload)
  File "/usr/lib/python3.3/email/generator.py", line 158, in _write_lines
self.write(laststripped)
  File "/usr/lib/python3.3/email/generator.py", line 395, in write
self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u0410' in position 
0: ordinal not in range(128)

But I might be using it wrong :/

--

___
Python tracker 

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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[R. David Murray]

R. David Murray added the comment:

__del__ methods are in general tricky because they are in the general case run 
asynchronously.  Therefore any proposal to "attach" the message to another 
message is a non-starter.

If a __del__ method depends on attributes set in the __init__, then the 
programmer needs to decide if they want to handle the possibility of __init__ 
failing, and therefore __del__ running without __init__ having completed.  For 
the stdlib, I think I'd lean toward handling such cases, in which case IMO the 
Pythonic thing to do is indeed to have a class attribute to provide the 
pre-__init__ default.

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

[issue19063] Python 3.3.3 encodes emails containing non-ascii data as 7bit

[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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[Guido van Rossum]

Guido van Rossum added the comment:

FWIW, using class attributes to ensure __del__ does not hit AttributeError when 
__init__ failed is more idiomatic than using three-argument getattr().

The reason: in general it is possible that __del__ calls almost any other 
method on a class (e.g. for a buffered I.O stream open for writing, __del__ 
might call close() which might attempt to flush the buffer).  It is not 
reasonable (and ugly :-) to use three-argument in all code that might be called 
by __del__.  But it is reasonable to use class attributes to pre-initialize 
instance variables set by __init__ to "safe" defaults like None.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The whole point of the special case ignoring of AttributeError in 
> __delete__ methods is that AttributeErrors are *expected* in certain
> circumstances.

You are completely misunderstanding this. There is no special case for 
AttributeError inside __del__, every exception is treated the same.
And by the way, this behaviour is documented:
http://docs.python.org/3.3/reference/datamodel.html#object.__del__
("Due to the precarious circumstances under which __del__() methods are 
invoked, exceptions that occur during their execution are ignored, and a 
warning is printed to sys.stderr instead.")

+1 for using a class attribute here, much cleaner than a getattr() dance.

--
nosy: +pitrou

___
Python tracker 

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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[Terry J. Reedy]

Terry J. Reedy added the comment:

The message problem can arise during exit if __del__ depends an any attribute 
of any object. It is hard to imagine a __del__ method that does not. Any 
__del__ method, including that of Popen, could handle AttributeErrors by 
wrapping the whole body in

try:
  
except AttributeError:
  pass

The is essentially what is done by the code that calls __del__, except that 
'pass' is replaced by "print(message, file=sys.stderr)".

If we patch Popen at all, I think this try:except should be the fix, not a 
class attribute.

To explain what I meant by the class attribute hack being tricky, consider the 
original version of Popen.__del__, minus the comments. 

def __del__(self, _maxsize=sys.maxsize, _active=_active):
if not self._child_created:
return
self._internal_poll(_deadstate=_maxsize)
if self.returncode is None and _active is not None:
_active.append(self)

Since self._internal_poll is an instance method, it is not a problem. But what 
about the self.returncode data attribute? Should we also add a class 
'returncode' attribute? If so, what should be its value? None? or object()? Or 
is it guaranteed that when _child_created is set true, returncode will be 
defined, so that a class attribute is not needed?

I don't know the answers to these questions. Popen.__init__ is about 130 lines 
and self._child_created is set to True in two other methods. I did not look 
where returncode is set, but it is not near the spots where _child_created is 
set True.

--

___
Python tracker 

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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[Terry J. Reedy]

Terry J. Reedy added the comment:

Reading Antoine's message more carefully, and the cited doc line, the generic 
fix to prevent the warning would be

try:
 <__del__ body>
except Exception:
  pass

The question is, do we only want to block the warning when someone calls Popen 
with the wrong number of arguments, or always?

--

___
Python tracker 

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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[R. David Murray]

R. David Murray added the comment:

No, that is not a good fix.  It would mask other programming errors.  There is 
a *reason* the error/traceback is printed when an error occurs.

The fact that the Popen logic may be a bit complex is not an argument in favor 
of a fix that hides errors.

--

___
Python tracker 

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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[Oleg Oshmyan]

Oleg Oshmyan added the comment:

> But what about the self.returncode data attribute? Should we also add a
> class 'returncode' attribute? If so, what should be its value? None? or
> object()? Or is it guaranteed that when _child_created is set true,
> returncode will be defined, so that a class attribute is not needed?

For what it's worth, returncode is indeed guaranteed to be defined when 
_child_created is True: it is initialized in __init__ before _execute_child is 
run. Of course, this does not help the general case of __del__ methods in other 
classes.

Silencing all AttributeErrors in all __del__ calls may be an easy and generic 
solution, but it will also hide genuine logic errors. I think it is reasonable 
to expect classes with __del__ to be careful about using attributes that exist, 
just like they must be careful about performing high-level operations that are 
valid in whatever state the object might be: destroy/close only things that 
have been created/opened, undo only actions that have been done etc.

--

___
Python tracker 

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

[issue19065] sqlite3 timestamp adapter chokes on timezones

[Chris Adams]

New submission from Chris Adams:

If you use detect_types=sqlite3.PARSE_DECLTYPES with sqlite3 and insert a 
timezone-aware datetime instance, you will get a ValueError if you attempt to 
read it back out: 

 File 
"/usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/sqlite3/dbapi2.py",
 line 68, in convert_timestamp
hours, minutes, seconds = map(int, timepart_full[0].split(b":"))
ValueError: invalid literal for int() with base 10: '03+00'

Although this immediately gets into the thorny stdlib timezone support 
situation, it's extremely annoying to have the out-of-the-box module break 
round-tripping data and it looks like support for simple UTC offsets isn't too 
horrible – something like https://gist.github.com/acdha/6655391 works in very 
limited testing:

def tz_aware_timestamp_adapter(val):
datepart, timepart = val.split(b" ")
year, month, day = map(int, datepart.split(b"-"))

if b"+" in timepart:
timepart, tz_offset = timepart.rsplit(b"+", 1)
if tz_offset == b'00:00':
tzinfo = datetime.timezone.utc
else:
hours, minutes = map(int, tz_offset.split(b':', 1))
tzinfo = datetime.timezone(datetime.timedelta(hours=hours, 
minutes=minutes))
else:
tzinfo = None

timepart_full = timepart.split(b".")
hours, minutes, seconds = map(int, timepart_full[0].split(b":"))

if len(timepart_full) == 2:
microseconds = int('{:0<6.6}'.format(timepart_full[1].decode()))
else:
microseconds = 0

val = datetime.datetime(year, month, day, hours, minutes, seconds, 
microseconds, tzinfo)

return val

sqlite3.register_converter('timestamp', tz_aware_timestamp_adapter)

--
components: Library (Lib)
messages: 198234
nosy: acdha
priority: normal
severity: normal
status: open
title: sqlite3 timestamp adapter chokes on timezones
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

[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list

[Terry J. Reedy]

Terry J. Reedy added the comment:

Right. If _internal_poll raises, it should not be masked as that would be a 
true bug.

More research. 'self.returncode = None' comes before the only call to the 
appropriate posix/windows version of ._execute_child(), which is the only place 
where '_child_created = True'. So class level
_child_created = False  # needed for __del__ if __init__ call fails
should be sufficient. With that added,
self._child_created = False
in __init__ would not be really needed. 

As I said on pydev, making the warning a Warning would be a different issue.

--

___
Python tracker 

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

[issue19065] sqlite3 timestamp adapter chokes on timezones

[R. David Murray]

Changes by R. David Murray :


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

[issue19024] Document asterisk (*), splat or star operator

[Terry J. Reedy]

Terry J. Reedy added the comment:

Index entries for * and ** were added in #12531 so that both are indexed as 
operators, in function definitions, in function calls, and in the tutorial. If 
any of these places need improvement, there should be specific suggestions.

I do not think there should be separate documentation for the * symbol. It 
would only duplicate what is already present. There are many symbols with 
multiple uses.

Changing html search search for symbols, if possible, would be a different 
issue. But returning every use of '*' in the docs would not seem too useful. 
For anything in the index, the index in more useful.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue19034] More useful repr for Tcl_Obj

[Terry J. Reedy]

Terry J. Reedy added the comment:

This looks more useful to me; it might make tests easier. But I cannot be sure 
no one would object.

--

___
Python tracker 

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

[issue19034] More useful repr for Tcl_Obj

[Raymond Hettinger]

Raymond Hettinger added the comment:

+1

--
nosy: +rhettinger

___
Python tracker 

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

[issue19024] Document asterisk (*), splat or star operator

[Raymond Hettinger]

Raymond Hettinger added the comment:

I concur with Terry.

--
nosy: +rhettinger

___
Python tracker 

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

[issue19021] AttributeError in Popen.__del__

[Oleg Oshmyan]

Oleg Oshmyan added the comment:

> Anothe possible solution is get rid from getattr and catch
> AttributeError instead.

Surely this would suffer from the same issue?

Why are the builtins getting deleted anyway? In fact, why is getattr getting 
deleted from the builtins module? The __builtins__ global is specifically not 
deleted when deleting modules to let destructors use builtins, and indeed the 
error message says "is not callable", suggesting the builtins module is still 
there but getattr is not. Is this perhaps some sort of IDLE bug?

--
nosy: +chortos

___
Python tracker 

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

[issue18990] Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

[Nick Coghlan]

Nick Coghlan added the comment:

An undocumented name without a leading underscore is always a bug, as it
means introspection and the prose docs give conflicting definitions of the
public API.

Whether the fix is to remove the offending name entirely, add a leading
underscore to mark it as private or document it as officially public is a
judgement call that needs to be made on a case by case basis.

--

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[anatoly techtonik]

New submission from anatoly techtonik:

If file to be executed with os.execv on Windows is located in directory with 
spaces, Python fails. This doesn't fail on Linux. To test, run:

  testexecv.py spaced

testexecv.py is attached.

--
components: Library (Lib), Windows
files: testexecv.py
messages: 198242
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.execv fails with spaced names on  Windows
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 
3.4, Python 3.5
Added file: http://bugs.python.org/file31837/testexecv.py

___
Python tracker 

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

[issue19050] crash while writing to a closed file descriptor

[Tim Peters]

Tim Peters added the comment:

Here with 2.7.5 on Windows (Vista):

C:\Python27>python.exe
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import io, sys
>>> fd = io.open(sys.stdout.fileno(), 'wb')
>>> fd.close()
>>> sys.stdout.write("now writing on stdout will cause a crash")

At this point Windows pops up a box saying "python.exe has stopped working".  I 
don't have a debug build available, and all I can find out is that it's a 
memory error in this line, somewhere in MS's C libraries:

and dword ptr ds:[718DD7A0h],0 

So, ya, it's a crash ;-)

--

___
Python tracker 

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