[issue15494] Move test/support.py into a test.support subpackage

[Martin v . Löwis]

Martin v. Löwis added the comment:

-1. test.support is not at all too large for a single module; there is no point 
in refactoring it.

Without a specific patch to review which proposes some specific change, I'm 
rejecting this change request.

--
nosy: +loewis
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue15232] email.generator.Generator doesn't mangle "From " lines in MIME preamble

[Chris Pickett]

Chris Pickett added the comment:

Thanks everyone!

--

___
Python tracker 

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

[issue15471] importlib's __import__() argument style nit

[Meador Inge]

Meador Inge added the comment:

How about the attached?

--
keywords: +patch
nosy: +meador.inge
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file26592/issue-15471.patch

___
Python tracker 

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

[issue15497] correct characters in TextWrapper.replace_whitespace docs

[Chris Jerdonek]

New submission from Chris Jerdonek:

This issue is to correct the list of whitespace characters to replace in the 
documentation for the textwrap module's TextWrapper.replace_whitespace 
attribute.

The documentation says this list is string.whitespace:

http://docs.python.org/dev/library/textwrap.html#textwrap.TextWrapper.replace_whitespace

However, the code deliberately avoids using string.whitespace and uses a 
hard-coded list of characters instead.  For example, see this code comment:

# Hardcode the recognized whitespace characters to the US-ASCII
# whitespace characters.  The main reason for doing this is that in
# ISO-8859-1, 0xa0 is non-breaking whitespace, so in certain locales
# that character winds up in string.whitespace

http://hg.python.org/cpython/file/917295aaad76/Lib/textwrap.py#l12

Patch attached.

--
assignee: docs@python
components: Documentation
files: issue-textwrap-whitespace.patch
keywords: easy, patch
messages: 166855
nosy: cjerdonek, docs@python
priority: normal
severity: normal
stage: patch review
status: open
title: correct characters in TextWrapper.replace_whitespace docs
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file26591/issue-textwrap-whitespace.patch

___
Python tracker 

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

[issue15494] Move test/support.py into a test.support subpackage

[Nick Coghlan]

Nick Coghlan added the comment:

Note that I don't think test.support itself should be broken up - I don't see 
any good reason to split the current grab bag of functionality out into 
submodules, so you'd just have support/__init__.py open instead.

This is really about giving us a better way to organise the *other* helper 
modules like script_helper and make them easier to find.

--

___
Python tracker 

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

[issue15496] harden directory removal for tests on Windows

[Jeremy Kloth]

New submission from Jeremy Kloth:

Currently, removing directories during testing on Windows w/NTFS can causing 
sporadic failures due to access denied errors.  This is caused by other 
processes getting a handle to the directory itself (change notifications) or a 
handle to a file within the directory.  The most notable offender is the 
Indexing Service.

Most (but not all!) external programs can be configured to ignore the 
development directory.  For example, the Indexing Service can be disabled or 
have those directories ignored.  TortoiseSVN is another offender that can 
exclude directories but each directory needs to be listed separately so it is 
easy to forgot one.  On my machine I have programs that simply do not have an 
option to ignore any directories thus causing some grief during testing.

The attached patch to test.support eliminates the need to disable or and 
ignores to any programs (tested on a Win7-x64 i7-3770K@4.3GHz).

It achieves this by checking for the removal of the directory before returning 
to the caller.  It performs an exponential backoff timeout loop that amounts to 
a total of ~1 second in the worst case.  If the directory is not removed from 
the filesystem by then, it will probably be in error anyway.  However, the loop 
is seldom executed more than once.

--
components: Tests
files: support.diff
keywords: patch
messages: 166853
nosy: jkloth
priority: normal
severity: normal
status: open
title: harden directory removal for tests on Windows
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26590/support.diff

___
Python tracker 

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

[issue15494] Move test/support.py into a test.support subpackage

[Ezio Melotti]

Ezio Melotti added the comment:

I'd prefer to keep test.support as a single module, rather than converting it 
to a package.
Most of the time I open up test.support when I'm trying to find some function, 
so having more files will only make this more complicated.

--
nosy: +ezio.melotti
type:  -> enhancement
versions: +Python 3.3, Python 3.4

___
Python tracker 

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

[issue15454] Allow dircmp.report() output stream to be customized

[Chris Calloway]

Changes by Chris Calloway :


--
nosy: +cbc

___
Python tracker 

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

[issue15495] enable type truncation warnings for gcc builds

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue15495] enable type truncation warnings for gcc builds

[Jeremy Kloth]

New submission from Jeremy Kloth:

It would seem that enabling GCC's type conversion/truncation warnings would be 
a good thing for Python builds.

This would bring GCC builds in line with MSVC builds and reduce the burden on 
the Windows developers in fixing them.  Also, it would bring attention to those 
issues by the developer who writes code and would hopefully understand the 
truncation issues at hand.

The CFLAGS required for this are '-Wconversion -Wno-sign-conversion'.

I unfortunately do not know the autoconf foo needed to implement this 
suggestion, however.  Perhaps it should only be enabled for debug builds as 
well to eliminate excess noise for other builds.  Or at least enabled on some 
of the buildbots.

--
components: Build
messages: 166851
nosy: jkloth
priority: normal
severity: normal
status: open
title: enable type truncation warnings for gcc builds
type: enhancement
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

> Later today I will create an issue to move test/support.py into a 
> test.support subpackage post-release.

I created issue 15494 for this.

--

___
Python tracker 

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

[issue15494] Move test/support.py into a test.support subpackage

[Chris Jerdonek]

Chris Jerdonek added the comment:

If people are okay with populating test/support/__init__.py with code (at least 
initially), the first patch could be to move support.py into 
test/support/__init__.py.  One nice thing about this approach is that the 
calling code won't need to change. 

The second patch could be to move test/script_helper.py into the package.

--

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

Sounds good.  Later today I will create an issue to move test/support.py into a 
test.support subpackage post-release.

We can continue the discussion of how to organize it there.

--

___
Python tracker 

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

[issue15494] Move test/support.py into a test.support subpackage

[Chris Jerdonek]

New submission from Chris Jerdonek:

This issue is to move test/support.py into a test.support subpackage as 
discussed in issue 15403.

This can be done post-release.

--
components: Tests
messages: 166848
nosy: cjerdonek, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Move test/support.py into a test.support subpackage

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Nick Coghlan]

Nick Coghlan added the comment:

The "release blocker" status comes from the test case I added in order to 
demonstrate the ability to strip a new frame sequence without needing to modify 
the C code.

Currently that test (failing to write the PYC file) fails with an IsADirectory 
traceback that includes a lot of importlib frames.

There are two possible solutions:
- redirect the affected call through "_call_with_frames_removed" but otherwise 
leave the failure intact
- change it so this particular case isn't a fatal error

I need to check if failing to write the .pyc was a fatal error in 3.2 before I 
decide how to fix it (unless someone else remembers off the top of their head)

--

___
Python tracker 

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

[issue15452] Improve the security model for logging listener()

[Nick Coghlan]

Nick Coghlan added the comment:

Yep, that's exactly the kind of hook I had in mind. That way the user can 
decide for themselves what level of scrutiny they want to apply.

--
title: Eliminate the use of eval() in the logging config implementation -> 
Improve the security model for logging listener()

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Nick Coghlan added the comment:

Discoverability is definitely a problem - part of that is a docs issue, since 
test.support is currently the only one mentioned in the prose docs.

One advantage to moving to a support subpackage is that we can lose the 
"helper" suffix from the names, while still allowing thematic divisions.

So, for example, we could have

# support.py -> support/__init__.py
import test.support
# script_helper.py -> support/scripts.py
import test.support.scripts
# Other possible additions
import test.support.imports
import test.support.network

Even without updating the prose docs, this would help discoverability a lot by 
having a much smaller directory listing to scan for useful support code. At the 
moment the general purpose helper modules are mixed in with the tests

I agree with Antoine that we're probably better off handling this as a refactor 
post-release at this point, though. I'd hoped to have the time to devote to it 
beforehand, but there's user facing stuff that's higher priority right now.

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le lundi 30 juillet 2012 à 00:55 +, Nick Coghlan a écrit :
> However, the -C option doesn't cover the case of *implicit* invocation
> of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in
> - the idea would that, unless -E is specified, then -C $PYTHONRUNFIRST
> would be implied.
> 
> To be honest, I *don't* think this latter capability should be built
> into the core implementation. Instead, I think it is more appropriate
> for it to be handled at a virtual environment level, so that it
> doesn't inadvertently affect invocation of other applications (like
> hg) that merely happen to be written in Python.

Well, it shouldn't if you don't start doing "export PYTHONRUNFIRST=...",
but instead set it from the calling Python process (possibly from
coverage itself).

Having to create virtual environments and whatnot just to enjoy this
feature sounds terribly tedious.

--

___
Python tracker 

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

[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

[Antoine Pitrou]

Antoine Pitrou added the comment:

> This is especially so with Python 2.7 still having a couple of years
> of full maintenance left - that's a long time to leave it with a known
> broken memoryview implementation. I'm less worried about 3.2, since
> the upgrade path to 3.3 is easier in that case, but even that version
> is likely to see widespread use for a long time.

Well, there's a reason we don't backport features to bugfix branches,
especially when we're talking about a complete rewrite of the
implementation.  So I really don't agree this should be backported.

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Nick Coghlan]

Nick Coghlan added the comment:

There are two different use cases here. "-C" tackles one of them, 
"PYTHONRUNFIRST" the other.

My original use case came from working on the Python test suite. In that suite, 
we have "test.script_helper" which spawns Python subprocesses in order to test 
various aspects of the startup machinery. I can easily modify script_helper to 
pass an extra -C argument when gathering coverage data, so I don't need any 
implicit magic.

The -C option also simplifies a whole host of things by letting you use the 
Python API to perform preconfiguration of various subsystems before executing 
__main__ normally rather than having to either write a custom launch script 
(difficult to do with full generality) or adding even more arcane command line 
options.

However, the -C option doesn't cover the case of *implicit* invocation of 
subprocesses. This is where the PYTHONRUNFIRST suggestion comes in - the idea 
would that, unless -E is specified, then -C $PYTHONRUNFIRST would be implied.

To be honest, I *don't* think this latter capability should be built into the 
core implementation. Instead, I think it is more appropriate for it to be 
handled at a virtual environment level, so that it doesn't inadvertently affect 
invocation of other applications (like hg) that merely happen to be written in 
Python. Scoping it to a venv would also lessen many of my security concerns 
with the idea. A simple way to do this would be if pyvenv.cfg could contain a 
customisation snippet that was executed prior to __main__ invocation (building 
off the -C machinery)

--

___
Python tracker 

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

[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

[Nick Coghlan]

Nick Coghlan added the comment:

I suspect the need to preserve the C ABI would make a complete backport a 
challenge. I'm still tempted though, mainly to give third parties a robust core 
implementation of the buffer API to test against.

This is especially so with Python 2.7 still having a couple of years of full 
maintenance left - that's a long time to leave it with a known broken 
memoryview implementation. I'm less worried about 3.2, since the upgrade path 
to 3.3 is easier in that case, but even that version is likely to see 
widespread use for a long time.

--
priority: high -> release blocker

___
Python tracker 

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

[issue15482] __import__() change between 3.2 and 3.3

[Brett Cannon]

Brett Cannon added the comment:

On Jul 29, 2012 5:58 AM, "Martin v. Löwis"  wrote:
>
>
> Martin v. Löwis added the comment:
>
> So should 3.2 be changed to adjust the default value to match the
documentation?

It is probably safe to do so.

-brett

>
> --
> nosy: +loewis
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15473] importlib no longer uses imp.NullImporter

[Brett Cannon]

Brett Cannon added the comment:

On Jul 29, 2012 12:21 AM, "Nick Coghlan"  wrote:
>
>
> Nick Coghlan added the comment:
>
> See the porting notes:
http://docs.python.org/dev/whatsnew/3.3.html#porting-python-code
>
> With the removal of the implicit default finder, the 3.3 semantics are
that both None *and* imp.NullImporter mean "There is no importer for this
path".

What Nick said is true, but for docs it's too broad a statement. Since
nullimporter inherently never finds anything it acts like there is no
importer. But the new behaviour is the use of None to represent that which
is the official semantics now.

-brett

>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15464] ssl: add set_msg_callback function

[Thiébaud Weksteen]

Thiébaud Weksteen added the comment:

I've updated the patch with this method of testing.

--
Added file: http://bugs.python.org/file26589/ssl_msg_callback-0.2.patch

___
Python tracker 

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

[issue15295] Import machinery documentation

[Brett Cannon]

Brett Cannon added the comment:

On Jul 29, 2012 2:09 AM, "Nick Coghlan"  wrote:
>
>
> Nick Coghlan added the comment:
>
> General comment:
>
> runpy, pkgutil, et al should all get "See Also" links at the top pointing
to the new import system section.
>
> Import system intro:
>
> As noted above, I suggest changing the name :)
>
> Opening section should refer to importlib.import_module(). Any mentions
of __import__ should point out that its API is designed for the convenience
of the interpreter, and thus it's a pain to use directly. However, we
should also document explicitly that, unlike the import statement and
calling __import__ directly, importlib.import_module will ignore any module
level replacements of __import__.
>
> Replacing builtins.__import__ won't reliably override the entire import
system (due to module level __import__ definitions, most notably
importlib.__import__) and other tools that work with the process global
import state directly (e.g. pkgutil, runpy).
>
> 5.1 Packages:
>
> Don't tease readers, just tell them: the defining characteristic of a
package is that it is a module object with a __path__ attribute.
>
> Since we have the privilege of defining *the* standard terminology for
old-style packages, I suggest we use the term "initialised" packages (since
having an __init__.py is what makes them special). We should also note
explicitly that an initialised package can also behave as a namespace
package, by setting __path__ appropriately in __init__.py
>
> Also, I suggest adding a 5.1.3 Package Example subheading - currently you
define an initialised package under the namespace package heading
>
> Finally, I think this section needs to explicitly define the terms
*import path* and *path entry*. The meta path docs later refer to
find_module() accepting a module name and path, and the reader could be
forgiven for thinking that meant a filesystem path, when it is actually an
import path (which is a sequence of path entries, which may themselves by
filesystem paths).
>
> 5.2.2 Finders and loaders:
>
> The term "sys path finder" is incorrect as registered path hooks are
invoked for both sys.path entries *and* package __path__ entries. I suggest
"path entry finder". (I agree a longer name is needed to better distinguish
them from metapath finders)
>
> 5.2.3 Import hooks:
>
> While it does get cleared up in 5.2.4, this section could be clearer that
the hooks *cannot* override the initial check of the module cache.
>
> 5.3.4 Metapath:
>
> See above comment about clarifying that an import path is passed to
find_module() rather than a filesystem path.
>
> The description of the path importer is incorrect. It only knows how to
scan an import path and interrogate the path hooks. It's the individual
path entry finders that know how to do things like load modules from the
filesystem or zip files.
>
>
> 5.2.5 Meta path loaders
>
> I don't like the title here. There's no such thing as a meta path loader.
there are only module loaders. Once they're created, it doesn't matter how
you found them.
>
> Clarify that the loader only has to remove the modules it inserted
itself. Other modules that were loaded *successfully* as a side effect of
the code execution will remain in the cache.
>
> 5.3 The Path Importer
>
> As noted above, the path importer is *NOT* restricted to filesystem
imports. All it cares about is arbitrary text sequences and path hooks.
With the right path hook, you could use URLs or database connection strings
as path entries.
>

Just so this doesn't get lost and in case it is important enough to block
on: it might be worth having separate ABCs for meta path finders and the
finders pathfinder uses since they have different APIs now (if one ignores
find_module for pathfinder finders). Just need to come up with names.

-brett

> 5.5 References
>
> I'd also point to PEP 328 (absolute imports by default and explicit
relative import syntax) and PEP 338 (using the import system to find
__main__)
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

[Chris Jerdonek]

Chris Jerdonek added the comment:

> > (3) the branch name should be diplayed somewhere on the page when 
> > browsing (or better yet, also in the URL itself).
>
> This seems to be a bug in hgweb, and you should report it upstream.

I filed an issue for this upstream as you suggested:

http://bz.selenic.com/show_bug.cgi?id=3559

--

___
Python tracker 

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

[issue14973] restore python2 unicode literals in "ur" strings

[Christian Heimes]

Christian Heimes added the comment:

As of #15096 I've closed this bug as "won't fix".

--
nosy: +christian.heimes
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Martin v . Löwis]

Martin v. Löwis added the comment:

> Well, I said it ("The upload directory is wrong in the buildmaster  
> configuration, I'm trying to fix that"), but perhaps it was too late.

Yes, tough luck.

--

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Roundup Robot]

Roundup Robot added the comment:

New changeset 89d9874dfd13 by Antoine Pitrou in branch 'default':
Closes #15493: fix link to daily DMG installer
http://hg.python.org/devguide/rev/89d9874dfd13

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Antoine Pitrou]

Antoine Pitrou added the comment:

Well, I said it ("The upload directory is wrong in the buildmaster 
configuration, I'm trying to fix that"), but perhaps it was too late.

--

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Martin v . Löwis]

Martin v. Löwis added the comment:

Actually, I had created a different directory.

I wish you had said from the beginning that you were going to look into it; it 
would have saved me some time.

--

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Martin v . Löwis]

Martin v. Löwis added the comment:

> No need to create it, I've already pointer the master.cfg to another
> directory (/data/www/buildbot/daily-dmg).

And indeed, that's the directory that I have just created. I also had
it put into the master.cfg, but you apparently overwrote my edit.

--

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I have now created the upload directory, let's see whether it fills
> (and no, it's still not on dinsdale).

No need to create it, I've already pointer the master.cfg to another
directory (/data/www/buildbot/daily-dmg).

--

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Martin v . Löwis]

Martin v. Löwis added the comment:

> I'm not sure who set up the web site link.

The current version of that link comes from Antoine Pitrou; I believe I put the 
original version on the website (before Brett moved it into the devguide).

The DMG uploading really can't work anymore since buildbot become its own 
system. In addition, the directory to upload to was not there on the machine, 
so all uploading failed.

I have now created the upload directory, let's see whether it fills (and no, 
it's still not on dinsdale).

--
nosy: +loewis

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Antoine Pitrou]

Antoine Pitrou added the comment:

> It looks like the buildbot is still building them:
> http://buildbot.python.org/all/buildslaves/bolen-dmg
> 
> I'm not sure who set up the web site link.

The upload directory is wrong in the buildmaster configuration, I'm
trying to fix that.

--

___
Python tracker 

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

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

[Ezio Melotti]

Ezio Melotti added the comment:

> So there may be three issues here:
> (1) the Dev Guide links to the revision list rather than directly
> to the browser,

This is now fixed.

> (2) browsing defaults to browsing 2.7 rather than the default branch,

This is fixed as well.  FTR it's not defaulting to 2.7, it just uses the branch 
of the latest commit, and when you checked it happened to be 2.7.

> (3) the branch name should be diplayed somewhere on the page when 
> browsing (or better yet, also in the URL itself).

This seems to be a bug in hgweb, and you should report it upstream.
In http://hg.python.org/cpython/rev/e8851809ae83 you can see at the top, next 
to the csid, the branch name and the 'tip' tag.
In http://hg.python.org/cpython/file/e8851809ae83 only the 'tip' tag is shown.
I don't know if the omission of the branch is intentional, but it seems 
reasonable to me to have it in the "browse" page too.

--
assignee:  -> ezio.melotti
components: +Devguide
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

___
Python tracker 

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

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

[Roundup Robot]

Roundup Robot added the comment:

New changeset 54ec1b493006 by Ezio Melotti in branch 'default':
#15491: change a couple more links to point to the "default" branch.
http://hg.python.org/devguide/rev/54ec1b493006

--

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Ned Deily]

Ned Deily added the comment:

It looks like the buildbot is still building them:
http://buildbot.python.org/all/buildslaves/bolen-dmg

I'm not sure who set up the web site link.

--

___
Python tracker 

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

[issue15493] No more Daily OS X installers

[Antoine Pitrou]

New submission from Antoine Pitrou:

The "Daily OS X installer" link in the devguide points to an empty directory 
(http://www.python.org/dev/daily-dmg/).

--
components: Devguide
messages: 166822
nosy: ezio.melotti, ned.deily, pitrou, ronaldoussoren
priority: low
severity: normal
status: open
title: No more Daily OS X installers

___
Python tracker 

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

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

[Antoine Pitrou]

Antoine Pitrou added the comment:

The "snapshot of py3k" link has the same issue.

--
nosy: +pitrou

___
Python tracker 

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

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0529e2062ec7 by Ezio Melotti in branch 'default':
#15491: link to the file list of the "default" branch.
http://hg.python.org/devguide/rev/0529e2062ec7

--
nosy: +python-dev

___
Python tracker 

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

[issue15489] Correct __sizeof__ support for BytesIO

[Antoine Pitrou]

Antoine Pitrou added the comment:

Thank you!

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

___
Python tracker 

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

[issue15489] Correct __sizeof__ support for BytesIO

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1d3155750808 by Antoine Pitrou in branch '3.2':
Issue #15489: Add a __sizeof__ implementation for BytesIO objects.
http://hg.python.org/cpython/rev/1d3155750808

New changeset 917295aaad76 by Antoine Pitrou in branch 'default':
Issue #15489: Add a __sizeof__ implementation for BytesIO objects.
http://hg.python.org/cpython/rev/917295aaad76

New changeset e8851809ae83 by Antoine Pitrou in branch '2.7':
Issue #15489: Add a __sizeof__ implementation for BytesIO objects.
http://hg.python.org/cpython/rev/e8851809ae83

--
nosy: +python-dev

___
Python tracker 

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

[issue15421] Calendar.itermonthdates OverflowError

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +belopolsky, ezio.melotti, rhettinger
stage:  -> patch review
type: enhancement -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

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

[issue15451] PATH is not honored in subprocess.Popen in win32

[Richard Oudkerk]

Richard Oudkerk added the comment:

> What I understand you two as saying is that there seems to be an 
> undocumented difference in execxxe between unix and windows which has been 
> carried over to subprocess.

No.  There is no difference between the platforms in the behaviour of 
os.execvpe().  os.execvpe() is simply implemented by trying execve() with a 
list of candidate executable paths until one of them works -- see _execvpe() in 
os.py.

Whether this difference from the behaviour of Posix's execvpe() was deliberate, 
I don't know.

The difference between the platforms in Python 2.x is caused by the fact that 
subprocess uses os.execvpe() on Unix and CreateProcess() on Windows.

In Python 3.x, os.execvpe() is no longer used on Unix, but the old behaviour 
has been deliberately maintained.  So the difference in behaviour is still 
present in Python 3.x.

--

___
Python tracker 

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

[issue1859] textwrap doesn't linebreak on "\n"

[Chris Jerdonek]

Chris Jerdonek added the comment:

If people are interested, I filed a new issue (issue 15492) about textwrap's 
tab expansion that I noticed while working on this issue.

--

___
Python tracker 

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

[issue15492] textwrap.wrap expand_tabs does not behave as expected

[Chris Jerdonek]

New submission from Chris Jerdonek:

While working on issue 1859, I noticed that textwrap.wrap()'s tab expansion 
does not seem to behave sensibly.

In particular, the documentation says, "If expand_tabs is true, then all tab 
characters in text will be expanded to zero or more spaces, *depending on the 
current column* and the given tab size."

The problem is that tab expansion is done as the first stage (and in 
particular, before wrapping), which means that "the current column" is no 
longer current after wrapping.  This leads to results like--

from textwrap import wrap

text = ("a\tb "
"a\tb")

lines = wrap(text, width=5, tabsize=4)
for line in lines:
print(repr(line))

Output:
'a   b'
'a b'

One would expect tab expansion to occur after (or while) wrapping, so that tab 
stops line up in the wrapped output.

--
messages: 166815
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: textwrap.wrap expand_tabs does not behave as expected

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Martin v . Löwis]

Martin v. Löwis added the comment:

The question really is what memory blocks can "leak out" of the object, and 
those don't really belong to the container. Those shouldn't be accounted for, 
since somebody else may get hold of them, and pass them to sys.sizeof.

For the PyAccu, AFAICT, objects cannot leak out of it (except for gc.getobjects 
in debug mode). So I think the memory allocated by the accu really belongs to 
the StringIO, and needs to be accounted there. The same goes for readnl, 
writenl, and weakreflist.

On a related note, I wonder why the tp_clear and tp_traverse functions for 
stringio are so short. Shouldn't it also visit "decoder"?

--
nosy: +loewis

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Antoine Pitrou]

Antoine Pitrou added the comment:

> > For some value of "correct", since the internal accumulator could hold
> > alive some unicode strings.
> 
> This is not a concern of __sizeof__, because these lists and strings are 
> managed by GC.

It is, since they are private and not known by the user.

--

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> For some value of "correct", since the internal accumulator could hold
> alive some unicode strings.

This is not a concern of __sizeof__, because these lists and strings are 
managed by GC.

> There's no narrow build anymore on 3.3.

I mean 2.7 and 3.2. I have written test for such case, but can't check if it 
correct.

--

___
Python tracker 

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

[issue1859] textwrap doesn't linebreak on "\n"

[Chris Jerdonek]

Chris Jerdonek added the comment:

Sorry, that link should have been--

http://hg.python.org/cpython/file/1d811e1097ed/Lib/textwrap.py#l12

(hg.python.org seems to default to the 2.7 branch.  I just filed an issue about 
this.)

--

___
Python tracker 

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

[issue15491] hg.python.org/cpython "browse" link defaults to 2.7

[Chris Jerdonek]

New submission from Chris Jerdonek:

I'm not sure if I'm filing this in the right place since I don't see 
hg.python.org in the tracker "components" list, but if one clicks on the 
"Browse online" link of the Dev Guide here:

http://docs.python.org/devguide/

One is taken to--

http://hg.python.org/cpython/

(which is actually the list of revisions rather than the browser).

But if one then clicks on the "browse" link in the left column, it seems to 
default to the 2.7 branch.

It is a bit confusing because the browser does not say the name of the branch 
at the top, which can lead to unknowingly browsing the wrong branch.

So there may be three issues here: (1) the Dev Guide links to the revision list 
rather than directly to the browser, (2) browsing defaults to browsing 2.7 
rather than the default branch, and (3) the branch name should be diplayed 
somewhere on the page when browsing (or better yet, also in the URL itself).

--
messages: 166810
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: hg.python.org/cpython "browse" link defaults to 2.7

___
Python tracker 

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

[issue1859] textwrap doesn't linebreak on "\n"

[Chris Jerdonek]

Chris Jerdonek added the comment:

In working on the patch for this issue, I also noticed that there is a minor 
error in the documentation of the replace_whitespace attribute.

The docs say that string.whitespace is used, but the code uses a hard-coded 
string and includes a comment explaining why string.whitespace should *not* be 
used.

http://hg.python.org/cpython/file/1102e86b8739/Lib/textwrap.py#l30

I will correct this in the patch, but if people think so, I could file it as a 
separate issue.

--

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Here is a patch that implements correct __sizeof__ for C implementation of 
> io.StringIO.

For some value of "correct", since the internal accumulator could hold
alive some unicode strings.

> I haven't tested the patch on narrow build.

There's no narrow build anymore on 3.3.

--

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26587/stringio_sizeof-3.2.patch

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of 
io.StringIO.

I haven't tested the patch on narrow build.

--
components: IO, Library (Lib)
files: stringio_sizeof-3.3.patch
keywords: patch
messages: 166807
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for StringIO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26586/stringio_sizeof-3.3.patch

___
Python tracker 

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

[issue15490] Correct __sizeof__ support for StringIO

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26588/stringio_sizeof-2.7.patch

___
Python tracker 

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

[issue15489] Correct __sizeof__ support for BytesIO

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26584/bytesio_sizeof-3.2.patch

___
Python tracker 

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

[issue15489] Correct __sizeof__ support for BytesIO

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of 
io.BytesIO.

--
components: IO, Library (Lib)
files: bytesio_sizeof-3.3.patch
keywords: patch
messages: 166806
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for BytesIO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26583/bytesio_sizeof-3.3.patch

___
Python tracker 

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

[issue15489] Correct __sizeof__ support for BytesIO

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26585/bytesio_sizeof-2.7.patch

___
Python tracker 

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

[issue15469] Correct __sizeof__ support for deque

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26582/deque_sizeof-2.7-2.patch

___
Python tracker 

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

[issue15469] Correct __sizeof__ support for deque

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26581/deque_sizeof-3.2-2.patch

___
Python tracker 

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

[issue15469] Correct __sizeof__ support for deque

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Patches updated. Now __sizeof__ is O(1) as Martin advised.

--
Added file: http://bugs.python.org/file26580/deque_sizeof-3.3-2.patch

___
Python tracker 

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

[issue15488] Closed files keep their buffer alive

[Benjamin Peterson]

Benjamin Peterson added the comment:

Sounds reasonable to me.

--

___
Python tracker 

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

[issue15451] PATH is not honored in subprocess.Popen in win32

[Terry J. Reedy]

Terry J. Reedy added the comment:

What I understand you two as saying is that there seems to be an undocumented 
difference in execxxe between unix and windows which has been carried over to 
subprocess. In particular, for both, the PATH component of the env parameter is 
used to search for the file on *nix but not on windows, even though this is not 
part of posix behavior. So reopening -- as a doc issue -- unless an os expert 
like Martin declares this to be a behavior bug.

Grissiom, can you verify that the difference still exists in 3.2/3?

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, loewis
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
versions: +Python 3.2, Python 3.3

___
Python tracker 

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

[issue633930] Nested class __name__

[Stefan Mihaila]

Stefan Mihaila added the comment:

Only an issue in Python2.

>>> A.B.__qualname__
'A.B'
>>> repr(A.B)
""

--
nosy: +mstefanro
versions: +Python 2.6, Python 2.7

___
Python tracker 

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

[issue15488] Closed files keep their buffer alive

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

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

[issue15488] Closed files keep their buffer alive

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson, hynek, stutzbach

___
Python tracker 

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

[issue15488] Closed files keep their buffer alive

[Antoine Pitrou]

New submission from Antoine Pitrou:

>>> f = open("LICENSE", "rb")
>>> sys.getsizeof(f)
4296
>>> f.close()
>>> sys.getsizeof(f)
4296

Instead of waiting for the file object's deallocation, perhaps we should free 
the buffer when it is closed?

--
components: IO, Library (Lib)
messages: 166801
nosy: pitrou
priority: low
severity: normal
status: open
title: Closed files keep their buffer alive
type: resource usage
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le dimanche 29 juillet 2012 à 17:45 +, Meador Inge a écrit :
> Anyway, the way you are implementing the tests has the same issue as Martin 
> pointed
> out for the 'object.__sizeof__' method in issue15402.  I could replace the 
> 'buffered_sizeof' implementation with:
> 
>static PyObject *
>buffered_sizeof(buffered *self, void *unused)
>{
>Py_ssize_t res;
> 
>res = 1;
>if (self->buffer)
>res += self->buffer_size;
>return PyLong_FromSsize_t(res);
>}
> 
> and the tests will still pass.

That's true but, OTOH, I don't think it's very important. First, because
it is a rather unlikely mistake. Second, because the important thing is
to check that the internal buffer is part of the returned size, which is
what Serhiy's test checks for.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Meador Inge]

Meador Inge added the comment:

On Sun, Jul 29, 2012 at 11:50 AM, Serhiy Storchaka  
wrote:

>> Serhiy, I didn't analyze it too in depth, but why aren't the test cases
>> using the __sizeof__ support work you implemented for issue15467?  I think
>> these tests should be using the more exact method like your other
>> '__sizeof__' patches.
>
> Because struct has not codes for Py_off_t and PyThread_type_lock.

Of course it doesn't -- those are Python specific typedefs.  
'PyThread_type_lock'
is just a typedef to 'void *' and something could be figured out for 'Py_off_t'
in the support code.

Anyway, the way you are implementing the tests has the same issue as Martin 
pointed
out for the 'object.__sizeof__' method in issue15402.  I could replace the 
'buffered_sizeof' implementation with:

   static PyObject *
   buffered_sizeof(buffered *self, void *unused)
   {
   Py_ssize_t res;

   res = 1;
   if (self->buffer)
   res += self->buffer_size;
   return PyLong_FromSsize_t(res);
   }

and the tests will still pass.

--
nosy: +loewis

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Antoine Pitrou]

Antoine Pitrou added the comment:

That said, given the nature of the patch (a cleanup without any functional 
impact), I don't think it should be a release blocker.

--

___
Python tracker 

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

[issue15452] Eliminate the use of eval() in the logging config implementation

[Vinay Sajip]

Vinay Sajip added the comment:

> As far as your other suggestion goes, don't reinvent crypto badly -
> if you want to provide authentication support in listener(), provide a
> hook that allows the application to decide whether or not to accept
> the configuration before it gets applied.

Well, that's fine. My earlier suggestion keeps the API change to a minimum, but 
I suppose there's no real need to be so minimal.

I suppose the basic approach would be to pass to listen() an optional verify 
callable (defaulting to None) which, if provided, would be called with the 
bytes received over the socket. That allows for e.g. signed or encrypted data. 
The value returned from the verify() call would be processed as the current 
received value is (allowing the verifier to transform the input, e.g. by 
decrypting it).

--

___
Python tracker 

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

[issue15436] __sizeof__ is not documented

[Martin v . Löwis]

Martin v. Löwis added the comment:

> I think there is one difference between __len__ and __sizeof__. __sizeof__ 
> should be overloaded only for C-implemented classes. IMHO, it is a part of C 
> API.

That is a reasonable point. So documenting it along with the type slots
might be best.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Antoine Pitrou]

Antoine Pitrou added the comment:

Thanks for the patch :)

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

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1102e86b8739 by Antoine Pitrou in branch '2.7':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/1102e86b8739

--

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le dimanche 29 juillet 2012 à 17:00 +, Chris Jerdonek a écrit :
> Chris Jerdonek added the comment:
> 
> > Less favorable, because it produces longer import strings
> ("test.support.some_helper" instead of "test.some_helper").
> 
> This can be addressed by exposing the API in __init__.py though (as
> does, say, the unittest package), no?

Yes, that's right.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8a02a93c803a by Antoine Pitrou in branch '3.2':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/8a02a93c803a

New changeset 1d811e1097ed by Antoine Pitrou in branch 'default':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/1d811e1097ed

--
nosy: +python-dev

___
Python tracker 

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

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

[Georg Brandl]

Georg Brandl added the comment:

Please reopen if you think it should be backported.

--

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

> Less favorable, because it produces longer import strings
("test.support.some_helper" instead of "test.some_helper").

This can be addressed by exposing the API in __init__.py though (as does, say, 
the unittest package), no?

--

___
Python tracker 

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

[issue15436] __sizeof__ is not documented

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not
> just an implementation detail of sys.getsizeof, just as __len__ is not an
> implementation detail of len(). Authors of extension types are supposed to
> implement it if object.__sizeof__ is incorrect.

I think there is one difference between __len__ and __sizeof__. __sizeof__ 
should be overloaded only for C-implemented classes. IMHO, it is a part of C 
API.

--

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Are you opposed to (2), or is it simply less favorable?

Less favorable, because it produces longer import strings
("test.support.some_helper" instead of "test.some_helper").

--

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

Thanks for your thoughts.  For the purposes of this patch, I will change to 
putting the new support functionality in test.support.  Going forward, if we 
could do some of the refactoring for 3.3.1, that would be great. :)

I worry that the third option may make things worse because it would become 
less obvious where all of the different test support functionality is located.

Are you opposed to (2), or is it simply less favorable?  The transition to (2) 
could be a gradual one beginning with two or even one module inside the package.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Serhiy, I didn't analyze it too in depth, but why aren't the test cases
> using the __sizeof__ support work you implemented for issue15467?  I think
> these tests should be using the more exact method like your other
> '__sizeof__' patches.

Because struct has not codes for Py_off_t and PyThread_type_lock.

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Chris Jerdonek]

Chris Jerdonek added the comment:

Okay, then in the interest of understanding why various alternatives fail, I'll 
just throw out the suggestion or question that I had in mind because I don't 
see it mentioned above or on the web page.

Why wouldn't it work to define an alias or script that invokes the desired 
"python -m ...", and then when you call your test suite (using a potentially 
different "-m ..."), you set sys.executable to that script so that subprocesses 
in your code under test will invoke it?  (coverage.py could do all of this 
under the hood so that the user need not be aware of it.)  Or would this work 
just fine, but that it's an example of the kind of hack that you're trying to 
avoid?

--

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Instead of putting this in MiscIOTest, you could use the relevant
> class-specific test cases.

Thank you, good advice. Here is updated patch.

--
Added file: http://bugs.python.org/file26579/bufferedio_sizeof-2.patch

___
Python tracker 

___diff -r d43ff8eb4cb3 Lib/test/test_io.py
--- a/Lib/test/test_io.py   Sun Jul 29 16:38:45 2012 +0200
+++ b/Lib/test/test_io.py   Sun Jul 29 19:30:56 2012 +0300
@@ -802,6 +802,20 @@
 buf.raw = x
 
 
+class SizeofTest:
+
+@support.cpython_only
+def test_sizeof(self):
+bufsize1 = 4096
+bufsize2 = 8192
+rawio = self.MockRawIO()
+bufio = self.tp(rawio, buffer_size=bufsize1)
+size = sys.getsizeof(bufio) - bufsize1
+rawio = self.MockRawIO()
+bufio = self.tp(rawio, buffer_size=bufsize2)
+self.assertEqual(sys.getsizeof(bufio), size + bufsize2)
+
+
 class BufferedReaderTest(unittest.TestCase, CommonBufferedTests):
 read_mode = "rb"
 
@@ -999,7 +1013,7 @@
  "failed for {}: {} != 0".format(n, 
rawio._extraneous_reads))
 
 
-class CBufferedReaderTest(BufferedReaderTest):
+class CBufferedReaderTest(BufferedReaderTest, SizeofTest):
 tp = io.BufferedReader
 
 def test_constructor(self):
@@ -1260,7 +1274,7 @@
 self.tp(self.MockRawIO(), 8, 12)
 
 
-class CBufferedWriterTest(BufferedWriterTest):
+class CBufferedWriterTest(BufferedWriterTest, SizeofTest):
 tp = io.BufferedWriter
 
 def test_constructor(self):
@@ -1650,7 +1664,7 @@
 # You can't construct a BufferedRandom over a non-seekable stream.
 test_unseekable = None
 
-class CBufferedRandomTest(BufferedRandomTest):
+class CBufferedRandomTest(BufferedRandomTest, SizeofTest):
 tp = io.BufferedRandom
 
 def test_constructor(self):
diff -r d43ff8eb4cb3 Modules/_io/bufferedio.c
--- a/Modules/_io/bufferedio.c  Sun Jul 29 16:38:45 2012 +0200
+++ b/Modules/_io/bufferedio.c  Sun Jul 29 19:30:56 2012 +0300
@@ -398,6 +398,17 @@
 Py_TYPE(self)->tp_free((PyObject *)self);
 }
 
+static PyObject *
+buffered_sizeof(buffered *self, void *unused)
+{
+Py_ssize_t res;
+
+res = sizeof(buffered);
+if (self->buffer)
+res += self->buffer_size;
+return PyLong_FromSsize_t(res);
+}
+
 static int
 buffered_traverse(buffered *self, visitproc visit, void *arg)
 {
@@ -1699,6 +1710,7 @@
 {"seek", (PyCFunction)buffered_seek, METH_VARARGS},
 {"tell", (PyCFunction)buffered_tell, METH_NOARGS},
 {"truncate", (PyCFunction)buffered_truncate, METH_VARARGS},
+{"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
 {NULL, NULL}
 };
 
@@ -2079,6 +2091,7 @@
 {"flush", (PyCFunction)buffered_flush, METH_NOARGS},
 {"seek", (PyCFunction)buffered_seek, METH_VARARGS},
 {"tell", (PyCFunction)buffered_tell, METH_NOARGS},
+{"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
 {NULL, NULL}
 };
 
@@ -2470,6 +2483,7 @@
 {"readline", (PyCFunction)buffered_readline, METH_VARARGS},
 {"peek", (PyCFunction)buffered_peek, METH_VARARGS},
 {"write", (PyCFunction)bufferedwriter_write, METH_VARARGS},
+{"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
 {NULL, NULL}
 };
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15487] Correct __sizeof__ support for buffered I/O

[Meador Inge]

Meador Inge added the comment:

Serhiy, I didn't analyze it too in depth, but why aren't the test cases using 
the __sizeof__ support work you implemented for issue15467?  I think these 
tests should be using the more exact method like your other '__sizeof__' 
patches.

--
nosy: +meador.inge
stage: needs patch -> patch review

___
Python tracker 

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

[issue15436] __sizeof__ is not documented

[Martin v . Löwis]

Martin v. Löwis added the comment:

rhettinger: users frequently need sys.getsizeof. See, for example,

http://stackoverflow.com/questions/1331471/in-memory-size-of-python-stucture
http://stackoverflow.com/questions/449560/how-do-i-determine-the-size-of-an-object-in-python
http://stackoverflow.com/questions/2117255/python-deep-getsizeof-list-with-contents
http://stackoverflow.com/questions/11301295/measure-object-size-accurately-in-python-sys-getsizeof-not-functioning
[and so on]

In what cases, do you think, it generates meaningless results? I find the 
results for the shared-keys dictionary quite meaningful and natural.

sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not just an 
implementation detail of sys.getsizeof, just as __len__ is not an 
implementation detail of len(). Authors of extension types are supposed to 
implement it if object.__sizeof__ is incorrect.

--
nosy: +loewis

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Sorry, on Martin's remarks.

--

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26578/itertools_sizeof-2.7-2.patch

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26577/itertools_sizeof-3.2-2.patch

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Patches updated on Meador's remarks. Tests updated to use new test.support 
helpers.

--
Added file: http://bugs.python.org/file26576/itertools_sizeof-3.3-2.patch

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Ned Batchelder]

Ned Batchelder added the comment:

Chris, I'm not sure how to answer your questions.  The more powerful and 
flexible, the better.  There is no "must" here.  I'm looking for a way to avoid 
the hacks coverage.py has used in the past to measure coverage in subprocesses. 
 A language feature that allowed me to externally configure the interpreter to 
run some of my code first would allow me to do that.

--

___
Python tracker 

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

[issue15467] Updating __sizeof__ tests

[Meador Inge]

Changes by Meador Inge :


--
stage:  -> committed/rejected
type:  -> behavior

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

I don't mind refactoring test support routines in maintenance release. I
said it was too late for 3.3 because the beta period is closing; but it
could be fine for 3.3.1 ;)

As for the way forward, I see three possibilites:
1) put everying in test.support, as a single module (that includes
folding script_helper into it)
2) make test.support a package of thematic modules
3) refactor test.support into a variety of independent modules
(script_helper, import_helper, socket_helper, etc.); a small
test.support providing fundamental features such as TESTFN could remain

My personal preference would be for 1) or 3). But whatever we choose, we
should do it consistently. Having a large test.support + a supportlib
package + some independent helpers is not a good idea.

--

___
Python tracker 

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

[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename

[Atsuo Ishimoto]

Atsuo Ishimoto added the comment:

+1 for keeping the file name unchanged. This solution is not very 
compatible with prior versions, but simple and least-surprise.

I prefer other platforms than Windows to use same method to build OSError.

--

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

At this point, would you advise me to add even more to the existing hodge 
podge, or to create a third sibling test support module?  My patch adds closely 
related test support functionality.

Incidentally, this discussion relates to the point I was getting at in the 
python-dev thread in the past couple days about how restrictions on refactoring 
test support code for maintenance releases can affect the quality of our test 
code.  I am still struggling with how to approach that.

--

___
Python tracker 

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

[issue633930] Nested class __name__

[Cheer Xiao]

Cheer Xiao added the comment:

There is a bigger problem:

>>> class C:
... class D:
... pass
...
>>> repr(C)
""
>>> repr(C.D)
""

Default repr on nested classes produce specious results.

The problem become pratical when you have two nested classes C1.D and C2.D in 
module m, which end up being both "m.D" in exception traceback. 

Classes nested in function are likely to contain some information from the 
function arguments and are thus different on each function call, making it 
impossible to have a general way to name them. Thus I propose embedding the 
resulting class's `id` in __name__, like what i'm doing manually in a hulking 
way:

>>> def factory(foo):
... class C(object):
... bar = foo
... func_name = 'factory'
... C.__name__ = '%s generated classobj at 0x%x' % (func_name, id(C))
... return C
...
>>> factory(0)

>>> factory(0)


Please consider reopening this issue.

--
nosy: +xiaq

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I feel like it is already too large (it is over 1750 lines), and I did
> not want to create a third sibling test support module (there is also
> test/script_helper.py that overlaps with test.support).  Do you think
> that the community would be open to refactoring test.support into a
> package for Python 3.3?  This was meant to assist in increasing test
> coverage for Python 3.3 bugs.

That's too late for 3.3, IMO. Whether or not test.support is too large
is a matter of taste (we have larger files in the stdlib; what makes
test.support annoying to work with is that it's a hodge-podge of utility
functions with little care for consistency). Unless we can clearly
separate it in thematic areas, making it a package would only make
finding stuff more difficult.

--

___
Python tracker 

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