[issue6560] socket sendmsg(), recvmsg() methods

[Charles-François Natali]

Charles-François Natali  added the comment:

> New changeset c64216addd7f by Nick Coghlan in branch 'default':
> Add support for the send/recvmsg API to the socket module. Patch by David 
> Watson and Heiko Wundram. (Closes #6560)
> http://hg.python.org/cpython/rev/c64216addd7f
>

I had actually started doing a review, I should have said so...
There was nothing spectacular though, so I'll just make some updates later.

--

___
Python tracker 

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

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

[Charles-François Natali]

Charles-François Natali  added the comment:

> I'm fine if you fix it, as I'm currently really short on time myself.

OK, I'll go ahead.

> For 3.3, it may be relevant that send/recvmsg are now available via the 
> socket API (see #6560).

Indeed. We might still need C code for the Windows part (I won't be
able to help much with Windows, I'm blissfully ignorant).

--

___
Python tracker 

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

[issue12775] immense performance problems related to the garbage collector

[Martin v . Löwis]

Martin v. Löwis  added the comment:

For the record, the speed improvement in 2.7 likely results from 79276316b94b. 
GC used to be quadratic with the number of objects, and is now only linear.

--

___
Python tracker 

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

[issue12780] Clean up tests for pyc/pyo in __file__

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Seems reasonable to me.  When did/does unicodedata ever have a __file__ 
attribute?

--

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[STINNER Victor]

STINNER Victor  added the comment:

> Where's the doc updates for the stable branches?

I don't know how to update this documentation. Can someone update the 
doc, or suggest a patch?

> Also, we might think about removing this version number everywhere.

Please, see my issue http://bugs.python.org/issue12795 for this topic.

--

___
Python tracker 

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

[issue6560] socket sendmsg(), recvmsg() methods

[Nick Coghlan]

Nick Coghlan  added the comment:

Someone here at the sprints pointed out a redundant unsigned comparison to 0 
that I missed, so a second set of eyes to double-check things like that would 
be good.

--

___
Python tracker 

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

[issue12811] Tabnanny doesn't close its tokenize files properly

[Nick Coghlan]

Changes by Nick Coghlan :


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

[issue12815] Coverage of smtpd.py

[Tennessee Leeuwenburg]

New submission from Tennessee Leeuwenburg :

Okay, I really don't know if I'm doing the right things to test meaningfully 
here. However, 100% coverage of the PureProxy class has been achieved.

I also slightly changed smtpd.py in a way that I'm not confident is what people 
would want. I pushed one print statement into the debug stream, and raised an 
exception in a place where it looked like the expected behaviour wasn't 
properly defined, but it's probably not a good place to fail if you're using 
the code.

I'm also not an SMTP expert... yes there's an RFC but I was going for coverage 
with "just enough" correctness.

I'm more than happy to revisit this work if anyone has any comments or issues, 
so just let me know.

--
files: PureProxy.diff
keywords: patch
messages: 142696
nosy: giampaolo.rodola, ncoghlan, tleeuwenburg
priority: normal
severity: normal
status: open
title: Coverage of smtpd.py
Added file: http://bugs.python.org/file22994/PureProxy.diff

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Georg Brandl wrote:
> 
> Also, we might think about removing this version number everywhere.

+1

--

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Martin v. Löwis wrote:
> 
> Martin v. Löwis  added the comment:
> 
>> So what about doing the same for FreeBSD, SunOS, and Windows?
> 
> I agree that's definitely out of scope of this issue.

We could change the title of the ticket :-)

>> If we're changing "linux2" / "linux3" to just "linux", we should be
>> consistent and do it for everybody.  I propose sys.platform under 3.3
>> should contain things like "linux", "freebsd", "openbsd", "darwin",
>> and "windows".
> 
> Definitely not. The reasoning that applies to Linux doesn't necessarily
> apply to the other systems. My understanding that it definitely does not
> apply to HP-UX, where major version number changes really indicate major
> changes (unlike in Linux).

Actually, with that reasoning we would need to reintroduce the
version for Mac OS, and even go a step further and add the minor
version number as well, since since major changes have happened on Mac OS
with every single minor release for the last couple of years.

IMO, a better approach is to split the information in two parts:

 * sys.platform, which only specifies the platform name on which
   Python was built (uname -s)

 * sys.platform_build_version, which provides the full platform
   version (uname -r; either as string or as tuple or both -
   that would have to be hashed out)

--

___
Python tracker 

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

[issue12794] platform: add a major function to get the system major version

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>> I'm not sure I understand why platform.release() isn't sufficient
>> for this purpose. Note that some systems return alphanumeric
>> values for platform.release(), e.g. for Windows you get
>> 'NT' or 'XP'.
> 
> It's not easy to get 2 (int) from '2.6.38-8-generic' (str). For Windows, 
> there *is* a major version:
> 
>  * Windows 3.1 : 3
>  * Windows 95/98, NT 4 : 4
>  * Windows XP, 2003 : 5
>  * Vista, Seven : 6
>
> The major version is maybe less revelant for Windows.

For Windows and Mac OS X, the minor version is relevant as well:

Windows 7 has the version number 6.1. For Mac OS X, there are major
changes happening for minor releases, e.g. see the architecture changes
between 10.4, 10.5 and 10.6.

> Anyway...
> 
>> platform.major() will be needed if we remove the major
>> version for all platforms from sys.platform (issue #12795).
> 
> I just closed the issue #12795, and so I don't think that this issue is still 
> needed and so I close it. Reopen it if you still see an use case.

--
title: platform: add a major function to get the system major version -> 
platform: add a major function to get the system major version

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[STINNER Victor]

STINNER Victor  added the comment:

> We could change the title of the ticket :-)

No please, move the discussion to #12795 which has a well defined title. This 
issue is closed. (#12795 has also a patch) Well, #12795 is also close but you 
can reopen it if you explain why :-)

--

___
Python tracker 

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

[issue12816] smtpd uses library outside of the standard libraries

[Tennessee Leeuwenburg]

New submission from Tennessee Leeuwenburg :

Hi,

I was writing some coverage tests, and started on a class called MailmanProxy 
inside of smtpd.py. It imports Mailman, which isn't in the standard library. 
I've attached a failing test to demonstrate the problem, but I didn't want to 
delete the section from smtpd.py as a beginner.

Thanks,
-Tennessee

--
components: Library (Lib)
files: MailmanProxy.diff
keywords: patch
messages: 142701
nosy: barry, ncoghlan, tleeuwenburg
priority: normal
severity: normal
status: open
title: smtpd uses library outside of the standard libraries
Added file: http://bugs.python.org/file22995/MailmanProxy.diff

___
Python tracker 

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

[issue12796] total_ordering goes into infinite recursion when NotImplemented is returned

[Nick Coghlan]

Nick Coghlan  added the comment:

This is a dupe of #10042

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> total_ordering

___
Python tracker 

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

[issue10042] total_ordering

[Nick Coghlan]

Nick Coghlan  added the comment:

Changed stage and resolution to reflect the fact that none of the existing 
patches adequately address the problem.

--
resolution: fixed -> 
stage: committed/rejected -> needs patch

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[Ezio Melotti]

Ezio Melotti  added the comment:

Having the major version in sys.platform only for a few selected platforms 
doesn't seem too consistent for me.

If linux 4 will introduce major changes, will we have to look for the major 
version of freebsd in sys.platform and for the linux major version elsewhere?

That said, removing the major version for the other platforms might introduce 
unnecessary breakage, but if it's ever going to happen, I think it's better to 
do it now for all the platforms and not waiting for the experts to speak and 
change it in later versions, adding even more inconsistency.

--
nosy: +ezio.melotti
stage:  -> committed/rejected

___
Python tracker 

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

[issue12794] platform: add a major function to get the system major version

[STINNER Victor]

STINNER Victor  added the comment:

Le 20/08/2011 21:25, Marc-Andre Lemburg a écrit :
> I'm not sure I understand why platform.release() isn't sufficient
> for this purpose.

You cannot write platform.release() >= (2, 28)  (Linux >= 2.28) or 
platform.release() >= 7  (FreeBSD 7 or later).

You may use int(platform.release()[0]) but it will fail after the major 
version 10, and I'm not sure that release() always starts with a digit.

> What we could do is add a function that tries to find out the
> true version number of the OS, e.g. for Windows 7 that would
> be (6, 1, 7601) instead of the marketing name '7' returned by
> platform.release().

Yes, it would be more pratical than release() and it would be possible 
to compare it using a tuple, like sys.version_info.

> Still, this won't help with the OS version used for the Python
> build.

I don't care of the OS version used to build. See my patch attached to 
#12795: only the version at runtime is important. The common use case is 
to check if the OS has a feature using its version, so the version at 
runtime.

> When Tarek was working on separating sysconfig from
> distutils, we briefly discussed parsing the Makefile and pyconfig.h
> files into a Python module.

This is now an issue: #9878. But it doesn't help if I need the version 
at runtime.

--

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Moved the discussion here from issue12326:

>> [Larry Hastings]
>> >> If we're changing "linux2" / "linux3" to just "linux", we should be
>> >> consistent and do it for everybody.  I propose sys.platform under 3.3
>> >> should contain things like "linux", "freebsd", "openbsd", "darwin",
>> >> and "windows".

> [Martin v. Löwis]
> > Definitely not. The reasoning that applies to Linux doesn't necessarily
> > apply to the other systems. My understanding that it definitely does not
> > apply to HP-UX, where major version number changes really indicate major
> > changes (unlike in Linux).

Actually, with that reasoning we would need to reintroduce the
version for Mac OS, and even go a step further and add the minor
version number as well, since since major changes have happened on Mac OS
with every single minor release for the last couple of years.

IMO, a better approach is to split the information in two parts:

 * sys.platform, which only specifies the platform name on which
   Python was built (uname -s)

 * sys.platform_build_version, which provides the full platform
   version (uname -r; either as string or as tuple or both -
   that would have to be hashed out)

It is obvious that the version number in sys.platform often 
doesn't really get used (see Victor's example). In such cases,
having access to just the build platform name is better.
In other cases, where you do need to know the version (e.g.
on Mac OS X), you can then easily get if from the new attribute,
and including the minor and even patch level release version
details (e.g. to determine whether Python was compiled with
a Windows specific service pack in place or not).

--
nosy: +lemburg
resolution: invalid -> 
status: closed -> open

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>> We could change the title of the ticket :-)
> 
> No please, move the discussion to #12795 which has a well defined title. This 
> issue is closed. (#12795 has also a patch) Well, #12795 is also close but you 
> can reopen it if you explain why :-)

Ok, I moved the discussion there.

--

___
Python tracker 

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

[issue12794] platform: add a function to get the system version as tuple

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
>> What we could do is add a function that tries to find out the
>> true version number of the OS, e.g. for Windows 7 that would
>> be (6, 1, 7601) instead of the marketing name '7' returned by
>> platform.release().
> 
> Yes, it would be more pratical than release() and it would be possible 
> to compare it using a tuple, like sys.version_info.

Ok, changed the title accordingly.

>> Still, this won't help with the OS version used for the Python
>> build.
> 
> I don't care of the OS version used to build. See my patch attached to 
> #12795: only the version at runtime is important. The common use case is 
> to check if the OS has a feature using its version, so the version at 
> runtime.

Well, it is important to somehow get the build information for
Python, since that tells us which OS features were available
at the time of compilation.

>> When Tarek was working on separating sysconfig from
>> distutils, we briefly discussed parsing the Makefile and pyconfig.h
>> files into a Python module.
> 
> This is now an issue: #9878. But it doesn't help if I need the version 
> at runtime.

True, those two data points are different.

--
title: platform: add a major function to get the system major   version -> 
platform: add a function to get the system   version as tuple

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[STINNER Victor]

STINNER Victor  added the comment:

FreeBSD or OpenBSD release major version frequently, something like one 
per year, or one per two years. FreeBSD and OpenBSD developers knows 
that for years, and Python programs use sys.platform.startswith() for 
these OSes.

For Linux, it's different. Linux 2.0 was released in 1997 and 3.0 in 
2011: it took 14 years to change the major version. It don't think that 
any program working on Linux was prepared for this change: see #12326 
history to have an idea on the problem. It looks like 
sys.platform=='linux3' breaks most programs testing sys.platform 
(including Python itself because of Lib/plat-linux2/ directory).

If you want the OS name, use platform.system() or os.uname()[0].

If you want the OS version, use platform.release(). If you want the OS 
version as a tuple, hum... see the issue #12794.

--

___
Python tracker 

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

[issue12808] Coverage of codecs.py

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Nick Coghlan wrote:
> 
> As a separate, but related point, IncrementalDecoder.getstate() includes an 
> explanation on how to save arbitrary state as an integer, but no such 
> explanation (not even a reference to the IncrementalDecoder version) is 
> present in the IncrementalEncoder.getstate() docs.
> 
> Adding MAL, since I'd like an expert opinion. Is the API less stringent than 
> the docs state, or should BufferedIncrementalEncoder be fixed to always 
> return the state as an integer?
> 
> [1] 
> http://docs.python.org/dev/library/codecs#codecs.IncrementalEncoder.getstate

I'm not sure how that description got into the docs. It must
have been added in the 3.x branch, since the 2.7 version of the
docs doesn't document those method at all.

FWIW: The .getstate() and .setstate() don't restrict the type of data
used for storing the state. The only requirement is that the data
returned by .getstate() can be passed to .setstate() in order to
recreate the internal state used by the codec:

def getstate(self):
"""
Return the current state of the encoder.
"""
return 0

def setstate(self, state):
"""
Set the current state of the encoder. state must have been
returned by getstate().
"""
For practical reasons, the used data should be pickleable.

The interface is very similar to the __getstate__/__setstate__
interface used by pickle.

--

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[Martin v . Löwis]

Martin v. Löwis  added the comment:

>> I agree that's definitely out of scope of this issue.
> 
> We could change the title of the ticket :-)

Please keep the issue closed... The issue at hand was that Linux 3
is released, and broke several applications. This issue has been
resolved.

For the other platforms, I don't see any issue to be fixed (except
for achieving "foolish consistency"). If something is *actually*
broken, it needs to be fixed.

--

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> FreeBSD or OpenBSD release major version frequently, something like one 
> per year, or one per two years. FreeBSD and OpenBSD developers knows 
> that for years, and Python programs use sys.platform.startswith() for 
> these OSes.
> 
> For Linux, it's different. Linux 2.0 was released in 1997 and 3.0 in 
> 2011: it took 14 years to change the major version. It don't think that 
> any program working on Linux was prepared for this change: see #12326 
> history to have an idea on the problem. It looks like 
> sys.platform=='linux3' breaks most programs testing sys.platform 
> (including Python itself because of Lib/plat-linux2/ directory).
> 
> If you want the OS name, use platform.system() or os.uname()[0].
> 
> If you want the OS version, use platform.release(). If you want the OS 
> version as a tuple, hum... see the issue #12794.

Victor, you are constantly mixing build time information with
runtime information. Those are two different types of information
and we should regard them as such.

sys.platform refers to build time information, so the platform
module won't help.

The version of the build platform is important to know, but
adding it to sys.platform is not necessarily the right
thing to do, since adding just the major version is often
not enough (see Mac OS X) and can sometimes lead to breakage
due to frequent new releases of OSes (see FreeBSD).

Given that the various OSes use different schemes for versioning
and backwards compatibility, a single string cannot possibly
cover all aspects.

Separating the information into OS name and version is a much
more future proof approach.

--

___
Python tracker 

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

[issue12794] platform: add a function to get the system version as tuple

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Well, it is important to somehow get the build information for
> Python, since that tells us which OS features were available
> at the time of compilation.

No, it doesn't (except for a bug that Matthias Klose pointed out).
The OS kernel version should have *zero* impact on the resulting Python
binary. What matters it the C compiler and the version of the C library.
The C library may or may not have features; features of the kernel used
to build Python are completely irrelevant.

(I think you misunderstood an earlier statement of me as
self-contradicting. It was not: The kernel *headers* may have an
impact during autoconf, not the running kernel. For Linux, the
kernel headers are part of the C library, and typically bear no
relationship with the running kernel - i.e. they may be either older
or newer than the running kernel).

Since there is no chance that we get the build environment captured
in a reasonable way (in particular not the version of the C library,
in a cross-platform manner), I strongly recommend to let this aspect
rest.

--
title: platform: add a function to get the system   version as tuple -> 
platform: add a function to get the system  version as  tuple

___
Python tracker 

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

[issue12768] docstrings for the threading module

[Eli Bendersky]

Eli Bendersky  added the comment:

The usual procedure for committing to both 3.2 and 3.3 is to apply a patch to 
3.2 and then merge it to 3.3 - could you check if the patch also works for 3.2 
and if not, generate a patch for 3.2? I will do the merge when committing.

--

___
Python tracker 

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

[issue12794] platform: add a function to get the system version as tuple

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Martin v. Löwis wrote:
> 
> Martin v. Löwis  added the comment:
> 
>> Well, it is important to somehow get the build information for
>> Python, since that tells us which OS features were available
>> at the time of compilation.
> 
> No, it doesn't (except for a bug that Matthias Klose pointed out).
> The OS kernel version should have *zero* impact on the resulting Python
> binary. What matters it the C compiler and the version of the C library.
> The C library may or may not have features; features of the kernel used
> to build Python are completely irrelevant.

We are now discussing the general case, not limited to Linux.

But even for Linux, the header information gets dumped into the
plat-linuxN directory files, and those change over time as well.
The kernel version also has an impact on certain features such
as real time clocks, timers or other kernel subsystems, which
autoconf then picks up at compile time.

Of course, you can check whether those features are available
one by one, but a version check is often a better way to see
whether your application has a chance of running on the Python
build in question.

For other OSes, the build version is much more important due
to the significant changes they make between releases, e.g.
Mac OS X.

> (I think you misunderstood an earlier statement of me as
> self-contradicting. It was not: The kernel *headers* may have an
> impact during autoconf, not the running kernel. For Linux, the
> kernel headers are part of the C library, and typically bear no
> relationship with the running kernel - i.e. they may be either older
> or newer than the running kernel).

I'm not talking about the runtime information. I'm talking
about the compile time build information which is available
via the Makefile and pyconfig.h file normally stored in the Python
installation and which is used by distutils.

The problem with those is that some distros choose to only
include those files in -dev packages and parsing them via
sysconfig just to get a quick look at the platform build
version is really a bit too much processing.

> Since there is no chance that we get the build environment captured
> in a reasonable way (in particular not the version of the C library,
> in a cross-platform manner), I strongly recommend to let this aspect
> rest.

We already do capture the build environment. This doesn't include
the C library version, but we could add that as well, if needed,
in a more direct way.

The platform module provides a way to determine the
lib C version required by the running Python binary on Linux
(and perhaps other OSes as well), but it's slow.

--

___
Python tracker 

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

[issue12808] Coverage of codecs.py

[Tennessee Leeuwenburg]

Tennessee Leeuwenburg  added the comment:

Some more tests, updated initial state of BufferedIncrementalEncoder to be the 
correct type, updated rst file. Bit tired, hope I got it right!

Thanks for the feedback everyone, helps me to get it done, even if it's more 
work for you...

--
Added file: http://bugs.python.org/file22996/codecs.diff

___
Python tracker 

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

[issue12794] platform: add a function to get the system version as tuple

[Martin v . Löwis]

Martin v. Löwis  added the comment:

>> No, it doesn't (except for a bug that Matthias Klose pointed out).
>> The OS kernel version should have *zero* impact on the resulting Python
>> binary. What matters it the C compiler and the version of the C library.
>> The C library may or may not have features; features of the kernel used
>> to build Python are completely irrelevant.
> 
> We are now discussing the general case, not limited to Linux.

And so was I. Read my statement as applying to the general case.

> But even for Linux, the header information gets dumped into the
> plat-linuxN directory files, 

Not in the build process, though...

> and those change over time as well.

What exactly changes over time? The plat-linuxN directory files?
Only if a developer updates them. For systems where the major
version indicates feature changes, the plat-OSn directory should
never change, since OS won't see any header changes until OSn+1
is released.

> The kernel version also has an impact on certain features such
> as real time clocks, timers or other kernel subsystems, which
> autoconf then picks up at compile time.

Which operating system specifically are you referring to here?
This should not happen.

> Of course, you can check whether those features are available
> one by one, but a version check is often a better way to see
> whether your application has a chance of running on the Python
> build in question.

That's a fragile approach, though. If the feature presence
varies with the OS kernel, you should rather check the version
of the kernel you are running on - it may be that support was
compiled in, but the system it runs on doesn't have that
support.

>> (I think you misunderstood an earlier statement of me as
>> self-contradicting. It was not: The kernel *headers* may have an
>> impact during autoconf, not the running kernel. For Linux, the
>> kernel headers are part of the C library, and typically bear no
>> relationship with the running kernel - i.e. they may be either older
>> or newer than the running kernel).
> 
> I'm not talking about the runtime information. I'm talking
> about the compile time build information which is available
> via the Makefile and pyconfig.h file normally stored in the Python
> installation and which is used by distutils.

And so am I. "running kernel" above refers to the kernel running
on the build system (i.e. what uname(1) gives you in autoconf,
and what currently gets into sys.platform).

> We already do capture the build environment. This doesn't include
> the C library version, but we could add that as well, if needed,
> in a more direct way.

No, we can't - that's impossible to implement in the general
case. Some systems may use static linking, or use a fixed version
number even as the library changes.

--

___
Python tracker 

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

[issue9200] Make str methods work with non-BMP chars on narrow builds

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee: belopolsky -> ezio.melotti

___
Python tracker 

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

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

[Stefan Krah]

New submission from Stefan Krah :

Hello,

in my private repo I've changed memoryview's getbufferproc to be PEP-3118
compliant. test_multiprocessing does the equivalent of the following sequence,
which is not allowed by PEP-3118:


>>> import array, io
>>> a = array.array('i', [1,2,3,4,5])
>>> m = memoryview(a)
>>> m.format
'i'
>>> buf = io.BytesIO(bytearray(5))
>>> buf.readinto(m)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: expected an object with a writable buffer interface
>>>


The error occurs in Objects/abstract.c:315:

   ((*pb->bf_getbuffer)(obj, &view, PyBUF_WRITABLE) != 0))


Here, PyObject_AsWriteBuffer() requests a simple writable buffer of unsigned
bytes *without format information* from the memoryview. The memoryview's
getbufferproc is required to return an error:

"If format is not explicitly requested then the format must be returned
 as NULL (which means "B", or unsigned bytes)."

But the underlying buffer has format 'i' and not 'B', hence the error.


Antoine, is it correct that io.BytesIO should only be used with bytearray
buffers?

If so, this is a bug in the tests (patch attached).

--
components: Tests
files: test_multiprocessing_use_bytearray.diff
keywords: needs review, patch
messages: 142718
nosy: ncoghlan, pitrou, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: test_multiprocessing: io.BytesIO() requires bytearray buffers
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: 
http://bugs.python.org/file22997/test_multiprocessing_use_bytearray.diff

___
Python tracker 

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

[issue11682] PEP 380 reference implementation for 3.3

[Ryan Kelly]

Changes by Ryan Kelly :


--
nosy: +rfk

___
Python tracker 

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

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

[Ryan Kelly]

Changes by Ryan Kelly :


--
nosy: +rfk

___
Python tracker 

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

[issue12794] platform: add a function to get the system version as tuple

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

[This discussion is really off-topic for this issue, it should either
 be moved to issue12795 or a new ticket]

Martin v. Löwis wrote:
> 
> Martin v. Löwis  added the comment:
> 
>>> No, it doesn't (except for a bug that Matthias Klose pointed out).
>>> The OS kernel version should have *zero* impact on the resulting Python
>>> binary. What matters it the C compiler and the version of the C library.
>>> The C library may or may not have features; features of the kernel used
>>> to build Python are completely irrelevant.
>>
>> We are now discussing the general case, not limited to Linux.
> 
> And so was I. Read my statement as applying to the general case.
> 
>> But even for Linux, the header information gets dumped into the
>> plat-linuxN directory files, 
> 
> Not in the build process, though...
>
>> and those change over time as well.
> 
> What exactly changes over time? The plat-linuxN directory files?
> Only if a developer updates them. For systems where the major
> version indicates feature changes, the plat-OSn directory should
> never change, since OS won't see any header changes until OSn+1
> is released.

I meant that the OS platform directories change over time,
i.e. new plat- directories get created to
hold the updated OS information.

Since Python was build on a specific OS version, it will only
see the APIs available on that OS version. The OS build
version provides a quick way to check whether a certain
set of feature is available or not.

>> The kernel version also has an impact on certain features such
>> as real time clocks, timers or other kernel subsystems, which
>> autoconf then picks up at compile time.
> 
> Which operating system specifically are you referring to here?
> This should not happen.

This is meant to happen. The whole purpose of autoconf/configure is
to try to figure out which features are available on a platform
and those features change with the OS version.

See e.g. these documents on the incremental Linux kernel changes
between 2.2 and 3.0:

http://www.kniggit.net/wwol22.html
http://www.kniggit.net/wwol24.html
http://www.kniggit.net/wwol26.html
http://jpranevich.tripod.com/wwol30/wonderful-world-of-linux-3.0.html

Here's a similar list for FreeBSD:

http://ivoras.net/freebsd/freebsd9.html
http://ivoras.net/freebsd/freebsd8.html
http://ivoras.net/freebsd/freebsd7.html

On Mac OS X the situations is a little different: older Python
binaries simply won't run on newer OS versions at all due to the
architecture changes, so there's nothing much to check.

>> Of course, you can check whether those features are available
>> one by one, but a version check is often a better way to see
>> whether your application has a chance of running on the Python
>> build in question.
> 
> That's a fragile approach, though. If the feature presence
> varies with the OS kernel, you should rather check the version
> of the kernel you are running on - it may be that support was
> compiled in, but the system it runs on doesn't have that
> support.

True, the feature may still not work in the runtime OS environment,
but at least the Python binary knows about the feature set you're
interested in, so you can actively check whether it works or not,
since the APIs will be available.

>>> (I think you misunderstood an earlier statement of me as
>>> self-contradicting. It was not: The kernel *headers* may have an
>>> impact during autoconf, not the running kernel. For Linux, the
>>> kernel headers are part of the C library, and typically bear no
>>> relationship with the running kernel - i.e. they may be either older
>>> or newer than the running kernel).
>>
>> I'm not talking about the runtime information. I'm talking
>> about the compile time build information which is available
>> via the Makefile and pyconfig.h file normally stored in the Python
>> installation and which is used by distutils.
> 
> And so am I. "running kernel" above refers to the kernel running
> on the build system (i.e. what uname(1) gives you in autoconf,
> and what currently gets into sys.platform).

Please don't mix up the build time environment with the
runtime environment. Using "running kernel" to refer to
the build time kernel is a rather confusing way of naming
things when discussing build time vs. runtime.

>> We already do capture the build environment. This doesn't include
>> the C library version, but we could add that as well, if needed,
>> in a more direct way.
> 
> No, we can't - that's impossible to implement in the general
> case. Some systems may use static linking, or use a fixed version
> number even as the library changes.

The platform API libc_ver() actually checks the linker references
in the binary and also allows using a different binary
for the check in case the Python binary is not a suitable
candidate.

It is mainly meant to identify the minimum lib C requirement
for a binary.

Adding the lib C version constants would make this information
more directly accessib

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

[Ezio Melotti]

Ezio Melotti  added the comment:

It turned out that this can't be fixed in 2.7 unless we backport the patch in 
#5127 (it's in 3.2/3.3 but not in 2.7).

IIUC the macro works fine and joins surrogate pairs to a Py_UCS4 char, but 
since the Py_UNICODE_IS* macros still expect Py_UCS2 on narrow builds on 2.7, 
the higher bits gets truncated and the macros return wrong results.

So, for example
>>> u'\ud800\udc42'.isupper()
True
because \ud800 + \udc42 = \U000100429  →  \U000100429 gets truncated to \u0429  
→  \u0429 is the CYRILLIC CAPITAL LETTER SHCHA  →  .isupper() returns True.

The current behavior is instead broken in another way, because it checks that 
u'\ud800'.isupper() and u'\udc42'.isupper() separately.

Would it make sense to backport #5127 or should I just give up and leave it 
broken?

--
title: Make str methods work with non-BMP chars on narrow builds -> Make the 
str.is* methods work with non-BMP chars on narrow builds

___
Python tracker 

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

[issue12816] smtpd uses library outside of the standard libraries

[R. David Murray]

R. David Murray  added the comment:

That was a correct decision :)

It certainly shouldn't be simply deleted, since that would break backward 
compatibility.  Barry, is this something we (ie: you, in this case :) wish to 
continue to maintain?

If not, we have the options of deprecation-and-removal, or deprecation-in-place 
(in the latter case we just stick a comment in the file...)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue12808] Coverage of codecs.py

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Tennessee Leeuwenburg wrote:
> 
> Tennessee Leeuwenburg  added the comment:
> 
> Some more tests, updated initial state of BufferedIncrementalEncoder to be 
> the correct type, updated rst file. Bit tired, hope I got it right!
> 
> Thanks for the feedback everyone, helps me to get it done, even if it's more 
> work for you...

I think you should simply drop this whole part:

"""
The implementation should make sure that ``0`` is the most common state. (States
that are more complicated than integers can be converted into an integer by
marshaling/pickling the state and encoding the bytes of the resulting string
into an integer).
"""

or, better, rephrase it so that it becomes clear that the codec
implementation may use any type of pickleable object to represent
the internal state. The only requirement is that .setstate()
has to be able to read back the state returned by .getstate().

We have codecs in the stdlib that return integers, bytes/string
and even tuples (see the io module and the UTF-16 codec as example),
so the documentation is clearly wrong.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com


2011-10-04: PyCon DE 2011, Leipzig, Germany43 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/

--

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[STINNER Victor]

STINNER Victor  added the comment:

> sys.platform refers to build time information,
> so the platform module won't help.

When I wrote my patch, I realized that sys.platform is used to get the runtime 
information, which is wrong. See the tests in Lib/test/test_*.py: they use 
sys.platform to check features of the running OS (kernel). It is mostly to test 
FreeBSD major version, and it looks like Python is build on the same FreeBSD 
major version that it is running on. Maybe because on FreeBSD, most programs 
are compiled instead of using prebuild packages (pkgadd).

--

___
Python tracker 

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

[issue12794] platform: add a function to get the system version as tuple

[STINNER Victor]

STINNER Victor  added the comment:

> The whole purpose of autoconf/configure is
> to try to figure out which features are available on a platform
> and those features change with the OS version.

Hum, not exactly. autoconf checks if a function exists or if a constant exists 
in the C headers and in the C library. You have to check it or your program (C 
file) will not compile (missing function/constant).

But it's not enough. The GNU libc provides functions which are only available 
on some recent Linux kernels. Depending on the running kernel, the function may 
fail with something like "not implemented error".

See for example the discussion about accept4():
http://bugs.python.org/issue10115

At Python level, you need to know the running kernel version to check if 
accept4() if available or not. Knowing if the kernel used to compile Python has 
accept4() or not doesn't help.

(If you use the compiled Python on an older libc (e.g. on another computer), 
you have another problem, but it's the problem of OS vendors, not of Python.)

--

___
Python tracker 

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

[issue12818] email.utils.formataddr incorrectly quotes parens inside quoted strings

[R. David Murray]

New submission from R. David Murray :

The attached test case fails.

--
assignee: r.david.murray
files: formataddr_paren_test.patch
keywords: easy, patch
messages: 142725
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.formataddr incorrectly quotes parens inside quoted strings
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22998/formataddr_paren_test.patch

___
Python tracker 

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

[issue9253] argparse: optional subparsers

[Zsolt Cserna]

Changes by Zsolt Cserna :


--
nosy: +csernazs

___
Python tracker 

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

[issue12794] platform: add a function to get the system version as tuple

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
title: platform: add a function to get the system   version as  tuple 
-> platform: add a function to get the system version as tuple

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>> sys.platform refers to build time information,
>> so the platform module won't help.
> 
> When I wrote my patch, I realized that sys.platform is used to get the 
> runtime information, which is wrong. See the tests in Lib/test/test_*.py: 
> they use sys.platform to check features of the running OS (kernel). It is 
> mostly to test FreeBSD major version, and it looks like Python is build on 
> the same FreeBSD major version that it is running on. Maybe because on 
> FreeBSD, most programs are compiled instead of using prebuild packages 
> (pkgadd).

Right. FreeBSD doesn't ship prebuilt binaries for packages -
it uses a very elegant "ports" collection, where everything gets
compiled on the target machine:

http://www.freebsd.org/ports/

So you don't really run into the issue of using a older Python build
on the system, unless you have an application which ships Python
along with the application package.

--

___
Python tracker 

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

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

[Stefan Krah]

Stefan Krah  added the comment:

Of course, there is another interpretation:

[PyBUF_FORMAT]

"The returned buffer must have true format information if this flag is 
provided. This would be used when the consumer is going to be checking for what 
'kind' of data is actually stored. An exporter should always be able to provide 
this information if requested. If format is not explicitly requested then the 
format must be returned as NULL (which means "B", or unsigned bytes)"


So, the returned buffer may have false format information ('B' vs. 'i'
in this case) if this flag is not provided.


Do you agree with this? I'll then make it explicit in the documentation.

--

___
Python tracker 

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

[issue12818] email.utils.formataddr incorrectly quotes parens inside quoted strings

[R. David Murray]

R. David Murray  added the comment:

Hmm.  The output of formataddr is not actually incorrect, it just overquotes 
compared to what is required by the RFC.  Attached is a fix, but since this 
isn't technically an RFC bug, I'm removing 3.2 and 2.7 from versions.

--
keywords:  -easy
stage:  -> patch review
type:  -> behavior
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22999/formataddr_paren_quote.patch

___
Python tracker 

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

[issue12816] smtpd uses library outside of the standard libraries

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I think it should be deprecated and eventually removed.  I don't remember why I 
put it in this file, and besides Mailman 3 won't use it.

--

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[STINNER Victor]

STINNER Victor  added the comment:

>> It is mostly to test FreeBSD major version, and it looks like Python is 
>> build on the same FreeBSD major version that it is running on. Maybe because 
>> on FreeBSD, most programs are compiled instead of using prebuild packages 
>> (pkgadd).
>
> Right. FreeBSD doesn't ship prebuilt binaries for packages

FreeBSD does ship prebuild Python packages.

--

___
Python tracker 

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

[Ezio Melotti]

Ezio Melotti  added the comment:

The attached patch adds the following 4 public macros to unicodeobjects.h:
  Py_UNICODE_IS_SURROGATE(ch)
  Py_UNICODE_IS_HIGH_SURROGATE(ch)
  Py_UNICODE_IS_LOW_SURROGATE(ch)
  Py_UNICODE_JOIN_SURROGATES(high, low)
and documents them.

Since _Py_UNICODE_NEXT is still private, I'll commit it later as part as #9200.

--
Added file: http://bugs.python.org/file23000/issue10542b.diff

___
Python tracker 

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti  added the comment:
> 
> The attached patch adds the following 4 public macros to unicodeobjects.h:
>   Py_UNICODE_IS_SURROGATE(ch)
>   Py_UNICODE_IS_HIGH_SURROGATE(ch)
>   Py_UNICODE_IS_LOW_SURROGATE(ch)
>   Py_UNICODE_JOIN_SURROGATES(high, low)
> and documents them.
> 
> Since _Py_UNICODE_NEXT is still private, I'll commit it later as part as 
> #9200.

Looks good.

--

___
Python tracker 

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

[issue12713] argparse: allow abbreviation of sub commands by users

[Christian Ziemski]

Christian Ziemski  added the comment:

After some interesting hours of work (learning about tests) I created a new 
patch, including my original code changes as in the former patch and the new 
additional tests as well.

--
Added file: http://bugs.python.org/file23001/abbrev_subcmds_plus_tests_3.3.patch

___
Python tracker 

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

[issue9993] shutil.move fails on symlink source

[Jonathan Niehof]

Jonathan Niehof  added the comment:

Éric, here's a quick docs-only patch against current default...does this do the 
job?

--
Added file: http://bugs.python.org/file23002/shutil_move_doc.patch

___
Python tracker 

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 77171f993bf2 by Ezio Melotti in branch 'default':
#10542: Add 4 macros to work with surrogates: Py_UNICODE_IS_SURROGATE, 
Py_UNICODE_IS_HIGH_SURROGATE, Py_UNICODE_IS_LOW_SURROGATE, 
Py_UNICODE_JOIN_SURROGATES.
http://hg.python.org/cpython/rev/77171f993bf2

--
nosy: +python-dev

___
Python tracker 

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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 06b30c5bcc3d by Ezio Melotti in branch '3.2':
#9200: The str.is* methods now work with strings that contain non-BMP 
characters even in narrow Unicode builds.
http://hg.python.org/cpython/rev/06b30c5bcc3d

New changeset e3be2941c834 by Ezio Melotti in branch 'default':
#9200: merge with 3.2.
http://hg.python.org/cpython/rev/e3be2941c834

--
nosy: +python-dev

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>>> It is mostly to test FreeBSD major version, and it looks like Python is 
>>> build on the same FreeBSD major version that it is running on. Maybe 
>>> because on FreeBSD, most programs are compiled instead of using prebuild 
>>> packages (pkgadd).
>>
>> Right. FreeBSD doesn't ship prebuilt binaries for packages
> 
> FreeBSD does ship prebuild Python packages.

The FreeBSD base distribution (which has the binaries
and, AFAIK, the only binaries that ship with FreeBSD) doesn't
include Python. It's in the ports collection, though,
and for those you have the option of installing prebuilt
binaries of the packages via pkg_add.

Still, that's not exactly the FreeBSD way of doing things :)
See the big warning in the pkg_add man page, various discussions
on the net and the pros/cons in the handbook:
http://www.freebsd.org/doc/handbook/ports-overview.html

But in general you are right: if you use system provided Python
packages, chances are that your runtime OS version will be
identical or very close to the build time OS version.

--

___
Python tracker 

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

[issue12795] Remove the major version from sys.platform

[STINNER Victor]

STINNER Victor  added the comment:

> But in general you are right: if you use system provided Python
> packages, chances are that your runtime OS version will be
> identical or very close to the build time OS version.

I asked on #freebsd-fr: even with pkg_add, the installed Python is compiled on 
the same major version than the running major version. So the problem is 
"hidden" (it doesn't affect) on FreeBSD.

--

___
Python tracker 

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

[issue12409] Moving "Documenting Python" to Devguide

[Brett Cannon]

Brett Cannon  added the comment:

+1

--
Added file: http://bugs.python.org/file23005/unnamed

___
Python tracker 

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

[issue12819] PEP 393 - Flexible Unicode String Representation

[Torsten Becker]

New submission from Torsten Becker :

I have started an implementation of PEP 393 -- Flexible String Representation 
[1] on bitbucket [2].  Not all code is ported to use the new API yet, but the 
interpreter starts with the new unicode representation, all unit tests pass, 
and some micro benchmarks show potential.  Please see the related wiki page [3] 
for details of my implementation.

[1]: http://www.python.org/dev/peps/pep-0393/
[2]: https://bitbucket.org/t0rsten/pep-393
[2]: http://wiki.python.org/moin/SummerOfCode/2011/PEP393

--
components: Unicode
files: pep-393-aug22.diff
keywords: patch
messages: 142741
nosy: torsten.becker
priority: normal
severity: normal
status: open
title: PEP 393 - Flexible Unicode String Representation
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23004/pep-393-aug22.diff

___
Python tracker 

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

[issue12819] PEP 393 - Flexible Unicode String Representation

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti, haypo, lemburg, loewis
stage:  -> patch review

___
Python tracker 

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

[issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)

[Remi Pointel]

Remi Pointel  added the comment:

Hi,
what information do you need to advance on this bug?
Cheers,
Remi.

--

___
Python tracker 

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

[issue12819] PEP 393 - Flexible Unicode String Representation

[STINNER Victor]

Changes by STINNER Victor :


--
hgrepos: +62

___
Python tracker 

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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

This issue and #5127 should not be backported to 2.7: narrow builds don't even 
accept unichar(0x1).
Only python 3 can slowly pretend to implement utf-16 features.

--

___
Python tracker 

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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

[STINNER Victor]

STINNER Victor  added the comment:

> This issue and #5127 should not be backported to 2.7:
> narrow builds don't even accept unichar(0x1).

I agee.

--

___
Python tracker 

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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 75a4941d4d61 by Ezio Melotti in branch '2.7':
#9200: backport tests but run them on wide builds only.
http://hg.python.org/cpython/rev/75a4941d4d61

--

___
Python tracker 

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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

[Ezio Melotti]

Ezio Melotti  added the comment:

Backporting #5127 is not possible anyway, because it would be necessary to 
recompile.
I backported only the tests, skipping them on wide builds.

--
dependencies:  -Py_UNICODE_NEXT and other macros for surrogates
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

___
Python tracker 

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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

[Ezio Melotti]

Ezio Melotti  added the comment:

s/skipping them on wide builds/skipping them on narrow builds/
On wide builds they work fine, on narrow builds they don't work and they can't 
be fixed.

--

___
Python tracker 

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

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I improved UTF16.__getitem__ to handle negative indexes and slices. The later 
uses the same adjustment as for indexes. An __iter__ method is not needed as 
str.__iter__ used __getitem__. I will take further discussion of this prototype 
to python-ideas list.

--
Added file: http://bugs.python.org/file23006/utf16.py

___
Python tracker 

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

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

[Terry J. Reedy]

Changes by Terry J. Reedy :


Removed file: http://bugs.python.org/file22900/utf16.py

___
Python tracker 

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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Julian Berman]

Julian Berman  added the comment:

>  we explicitly advise against importing too many modules in a single import 
> statement, but importing multiple names from a single location is often a 
> useful thing to do.

Cool. I imagined this had to do with it.

> there may be a grammar ambiguity problem in this case, since (unlike 
> from-import) with statements allow arbitrary subexpressions.

Sorry, can you possibly clarify where the ambiguity might come in?

--

___
Python tracker 

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

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

[Roundup Robot]

Roundup Robot  added the comment:

New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default':
#12191: add shutil.chown() to change user and/or group owner of a given path 
also specifying their names.
http://hg.python.org/cpython/rev/d1fd0f0f8e68

--
nosy: +python-dev

___
Python tracker 

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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

[Sandro Tosi]

Sandro Tosi  added the comment:

At last, it's in :) thanks a lot to all the people that helped me in the 
process!

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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default'

You may add shutil.chmod to the "What's New in Python 3.3?" document.

--

___
Python tracker 

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

[issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map

[Éric Araujo]

Changes by Éric Araujo :


--
resolution: accepted -> fixed
stage: commit review -> committed/rejected

___
Python tracker 

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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

[Ezio Melotti]

Ezio Melotti  added the comment:

Raymond, are you still taking care of the whatsnew?
Do you want people to update it when they add something new?

--
nosy: +rhettinger

___
Python tracker 

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

[issue12409] Moving "Documenting Python" to Devguide

[Sandro Tosi]

Changes by Sandro Tosi :


Removed file: http://bugs.python.org/file23005/unnamed

___
Python tracker 

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

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Antoine, is it correct that io.BytesIO should only be used with bytearray
> buffers?

BytesIO does a copy of the original object, it does not touch the
original buffer.

--

___
Python tracker 

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

[issue11564] pickle not 64-bit ready

[Nadeem Vawda]

Nadeem Vawda  added the comment:

> Can you replace "_2G" with "_4G" in the decorator for that test?

When I do that, it pushes the memory usage for the test up to 16GB, which is
beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4),
that was enough to make it swap heavily (and in the end the test still failed).

As an aside, it turns out the problem with -M being ignored wasn't due to me
being stupid; it seems that -j doesn't pass the memlimit on to subprocesses.
I'll open a separate issue for this.

--

___
Python tracker 

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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5d317e38da44 by Sandro Tosi in branch 'default':
#12191: fix build failures, explicitly passing group argument when I want to 
test it
http://hg.python.org/cpython/rev/5d317e38da44

--

___
Python tracker 

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

[issue12792] Document the "type" field of the tracker in the devguide

[Ezio Melotti]

Ezio Melotti  added the comment:

Fixed in aa627513fb23.  I also moved the 'behavior' at the beginning of the 
list.

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

[issue11564] pickle not 64-bit ready

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > Can you replace "_2G" with "_4G" in the decorator for that test?
> 
> When I do that, it pushes the memory usage for the test up to 16GB, which is
> beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4),
> that was enough to make it swap heavily (and in the end the test still 
> failed).

Uh, does it? With 4G it should raise OverflowError, and not try to do
anything else.
Could I ask you to try to take a look? :S

> As an aside, it turns out the problem with -M being ignored wasn't due to me
> being stupid; it seems that -j doesn't pass the memlimit on to subprocesses.
> I'll open a separate issue for this.

Running bigmem tests in parallel doesn't make much sense IMO. You want
to run as many of them as you can, which requires that you allocate all
memory to *one* test process.

--

___
Python tracker 

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

[issue11564] pickle not 64-bit ready

[Nadeem Vawda]

Nadeem Vawda  added the comment:

> Uh, does it? With 4G it should raise OverflowError, and not try to do
> anything else.
> Could I ask you to try to take a look? :S

Sure; I'll see what I can figure out tomorrow.

> Running bigmem tests in parallel doesn't make much sense IMO. You want
> to run as many of them as you can, which requires that you allocate all
> memory to *one* test process.

Yeah, actually running them in parallel isn't a sensible use. But it bit me
because I was just using "make test EXTRATESTOPTS='-uall -M11G test_pickle'".
It would be nice to have a warning so other people don't get confused by the
same problem. I guess that shouldn't be too hard to arrange.

--

___
Python tracker 

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

[issue12409] Moving "Documenting Python" to Devguide

[Sandro Tosi]

Sandro Tosi  added the comment:

@Fred: thanks about it :)

@Éric: I just want to have clear in mind what you mean; my original proposal 
was to move completely, the whole section "Documenting python" to devguide 
since it contains building instructions and how's the markup works for python. 
Is your proposal different and so, as I can read, to just move the building 
part to devguide and the rest of it be left in python documentation with links 
to sphinx upstream documentation?

But one aspect I think it needs to be done as a prerequisite to this migration 
is: standardizing the sphinx/tools versions used to build the doc.

devguide is version-agnostic, so we can talk about (without convoluted 
sentences) only about one way to build the doc.

This was raised several times, even recently, on python-dev so I'm going to 
resurrect that thread so we can discuss there the pros/cons and then see from 
the outcome how we can move forward.

--
stage:  -> needs patch

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[Georg Brandl]

Georg Brandl  added the comment:

> I don't know how to update this documentation. Can someone update the 
> doc, or suggest a patch?

This is a strange statement. You changed the implementation, so you should be 
able to change the documentation accordingly.

--

___
Python tracker 

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

[issue11715] Building Python on multiarch Debian and Ubuntu

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Aug 18, 2011, at 07:09 AM, Nick Coghlan wrote:

>I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my
>netbook and updating to the latest Py3k code, I got a lot of test errors,
>even after a make distclean and ./configure.

Hi Nick.  Would this be Kubuntu 11.04 or some other release?

--

___
Python tracker 

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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

[Éric Araujo]

Éric Araujo  added the comment:

Ezio: I think that Raymond is in charge of the 3.3 whatsnew too.  The rules in 
a comment at the top of the file still apply: there are already around 30 notes 
to the file.

--

___
Python tracker 

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

[issue9993] shutil.move fails on symlink source

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the doc patch, which looks good.  I have one question: if a relative 
symlink is copied, should the resulting symlink be relative too?

--

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[STINNER Victor]

STINNER Victor  added the comment:

Something like:

diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -699,20 +699,21 @@ always available.
This string contains a platform identifier that can be used to append
platform-specific components to :data:`sys.path`, for instance.
 
-   For Unix systems, this is the lowercased OS name as returned by ``uname -s``
-   with the first part of the version as returned by ``uname -r`` appended,
-   e.g. ``'sunos5'`` or ``'linux2'``, *at the time when Python was built*.
-   Unless you want to test for a specific system version, it is therefore
-   recommended to use the following idiom::
+   For Unix systems, except on Linux, this is the lowercased OS name as
+   returned by ``uname -s`` with the first part of the version as returned by
+   ``uname -r`` appended, e.g. ``'sunos5'`` or ``'linux2'``, *at the time when
+   Python was built*.  Unless you want to test for a specific system version,
+   it is therefore recommended to use the following idiom::
 
-  if sys.platform.startswith('linux'):
-  # Linux-specific code here...
+  if sys.platform.startswith('freebsd'):
+  # Freebsd-specific code here...
 
For other systems, the values are:
 
 ===
System   :data:`platform` value
 ===
+   Linux``'linux2'``
Windows  ``'win32'``
Windows/Cygwin   ``'cygwin'``
Mac OS X ``'darwin'``

?

I don't think that I need a :versionchanged:`2.7.3`.

--

___
Python tracker 

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

[issue6484] No unit test for mailcap module

[Roundup Robot]

Roundup Robot  added the comment:

New changeset a1bb07d67a24 by Ezio Melotti in branch 'default':
#6484: refactor a bit the tests.
http://hg.python.org/cpython/rev/a1bb07d67a24

--

___
Python tracker 

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

[issue12713] argparse: allow abbreviation of sub commands by users

[Éric Araujo]

Éric Araujo  added the comment:

Reviewed.  Steven: the patch is complete, pending a few doc editions.

--

___
Python tracker 

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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

[Ezio Melotti]

Ezio Melotti  added the comment:

I think the doc patch should mention that:
 1) it's 'linux2' also on Linux 3;
 2) why it's not 'linux3';
The why can be done in a footnote and explain that Linux 3 doesn't introduce 
new major features and that changing the string to 'linux3' would have just 
broken needlessly code that was checking for sys.platform == 'linux2'.
It should probably also mention that in future versions (i.e. 3.3+) this string 
has been changed to be just 'linux' and that keep checking for sys.platform == 
'linux2' is therefore discouraged even after this change.

--

___
Python tracker 

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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

[Roundup Robot]

Roundup Robot  added the comment:

New changeset f2cb733c9a37 by Sandro Tosi in branch 'default':
#12191: added entry in What's New (+ small editing on shutil section)
http://hg.python.org/cpython/rev/f2cb733c9a37

--

___
Python tracker 

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

[issue9893] Usefulness of the Misc/Vim/ files?

[Éric Araujo]

Éric Araujo  added the comment:

> To download the current release of python.vim, which is an enhanced
> version of the python syntax highlighting script that conforms with
> PEP 8, and is actively maintained by the Vim community.
s/python/Python/

I think the bit about “enhanced version” could be puzzling.  Either say “an 
enhanced version of the python.vim file that used to be included in the Python 
repository”, or just delete that part (my preference).

> To update your .vimrc configuration file with Python-appropriate
> settings, use the sample file from Misc/Vim/vimrc.
The idea is to delete all of Misc/Vim.

> More comprehensive integration of Vim with Python tools and
> frameworks can be found at:
>
>http://sontek.net/turning-vim-into-a-modern-python-ide
I’m not sure we want to add links to specific articles; for example, I had to 
combine tips from many websites/blogs to have an efficient setup.  I suggest 
our README.vim only points to wim.org pages, and other links can be added to 
the Vim wikis.

--

___
Python tracker 

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

[issue9893] Removing the Misc/Vim/ files

[Éric Araujo]

Changes by Éric Araujo :


--
components: +None -Demos and Tools
title: Usefulness of the Misc/Vim/ files? -> Removing the Misc/Vim/ files
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue12678] test_packaging and test_distutils failures under Windows

[Éric Araujo]

Éric Araujo  added the comment:

>> Looks like the patch is not enough:
> That's a 3.2 builder. You only committed Jeremy's fix to default.
*puts on the stupid hat*

> I also tried backporting Jeremy's fix to 2.7, but that doesn't seem to
> have worked; the sdist tests is still failing there.
I’ll commit the tmp-debug patch so that we can get info from the buildbot, 
unless Jeremy or someone can investigate.

> test_record_extensions still needs attention, though.
I was hoping 49b4b4ba9f93 would be enough :(

--

___
Python tracker 

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

[issue12785] list_distinfo_file is wrong

[Éric Araujo]

Éric Araujo  added the comment:

Thanks.  Can you test again after removing these two lines:

# XXX see first if we need to convert at all
prefix = self.path

--

___
Python tracker 

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

[issue12808] Coverage of codecs.py

[Tennessee Leeuwenburg]

Tennessee Leeuwenburg  added the comment:

Thanks for the review. Here is a patch incorporating the two comments being to 
move some comments.

--
Added file: http://bugs.python.org/file23007/codecs.diff

___
Python tracker 

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

[issue12785] list_distinfo_file is wrong

[Éric Araujo]

Éric Araujo  added the comment:

Ahem, I read your message too fast.

> With the patch applied, I still get failures in test_old_record_extensions
> and test_record_basic, so it doesn't seem to work.
These are unrelated, I’m only interested in test_database for this patch.

--

___
Python tracker 

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

[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files

[Éric Araujo]

Éric Araujo  added the comment:

> While writing my tests I realized, it would be really useful to make
> write_file() return the path it wrote to.
Sure, please open another 3.3 report for this.

--

___
Python tracker 

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

[issue12409] Moving "Documenting Python" to Devguide

[Éric Araujo]

Éric Araujo  added the comment:

My comment was ambiguous, let me rephrase it: I am in favor of moving 
cpython/Doc/documenting to the devguide.  Then, in the devguide, I would like 
to remove all the doc that’s just duplicating the upstream Sphinx docs, keeping 
only links and Python-specific parts.

> But one aspect I think it needs to be done as a prerequisite to this 
> migration is:
> standardizing the sphinx/tools versions used to build the doc.
If this gets rejected, we can move the Documenting tree to the devguide anyway, 
we’ll just have to add a few paragraphs for 2.7 differences.

--

___
Python tracker 

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

[issue12394] packaging: generate scripts from callable (dotted paths)

[Éric Araujo]

Changes by Éric Araujo :


Added file: http://bugs.python.org/file23008/7099110c8f14.diff

___
Python tracker 

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