[issue12274] "Print window" menu on IDLE aborts whole application

[Gabriel Genellina]

Gabriel Genellina  added the comment:

Note: There is a much bigger problem here: IDLE should not abort abruptly in 
such cases, without any error indication.

--

___
Python tracker 

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

[issue12274] "Print window" menu on IDLE aborts whole application

[Gabriel Genellina]

New submission from Gabriel Genellina :

On Windows, IDLE closes all open windows and exits completely, without any 
error message, when selecting the "Print window" menu command.

Starting IDLE from inside a console, one can see the error message:

Exception in Tkinter callback
Traceback (most recent call last):
  File "D:\apps\python32\lib\tkinter\__init__.py", line 1399, in __call__
return self.func(*args)
  File "D:\apps\python32\lib\idlelib\IOBinding.py", line 453, in print_window
command = idleConf.GetOption('main','General','print-command-win')
  File "D:\apps\python32\lib\idlelib\configHandler.py", line 245, in GetOption
type=type, raw=raw)
  File "D:\apps\python32\lib\idlelib\configHandler.py", line 54, in Get
return self.get(section, option, raw=raw)
  File "D:\apps\python32\lib\configparser.py", line 789, in get
d)
  File "D:\apps\python32\lib\configparser.py", line 391, in before_get
self._interpolate_some(parser, option, L, value, section, defaults, 1)
  File "D:\apps\python32\lib\configparser.py", line 440, in _interpolate_some
"found: %r" % (rest,))
configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found
: '%s'


It is trying to read this entry from the config-main.def file:

[General]
print-command-posix=lpr %s
print-command-win=start /min notepad /p %s

For a ConfigParser file, those %s should be %%s instead. Previous IDLE versions 
(2.7 and 3.1) read the same entry without problem; I suspect they were using a 
RawConfigParser or processing the entry in a different way.

As a workaround, replacing %s with %%s in config-main.def is enough, until the 
code gets fixed.

--
components: IDLE
messages: 137789
nosy: gagenellina
priority: normal
severity: normal
status: open
title: "Print window" menu on IDLE aborts whole application
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Updated the title to reflect that the peephole optimizer will likely continue 
to exist but in a much simpler form.  Some complex peephole optimization such 
as constant folding can be handled more easily and more robustly at the AST 
level.

Other minor peephole optimizations such as jump-to-jump simplification as still 
bytecode level optimizations (ones that improve the quality of the generated 
code without visibility to higher level semantics).

--
title: Rewrite peephole to work on AST -> Build-out an AST optimizer, moving 
some functionality out of the peephole optimizer

___
Python tracker 

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

[issue12273] Change ast.__version__ calculation to provide consistent ordering

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I would like to change the version number calculation to something
> like:
> 
> '9.x.y.zzz'
> 
> where
> 
> 9 is a prefix to get 3.3+ ast.__version__ values to sort higher than
> earlier versions x.y is the Python version so later versions sort
> higher than earlier versions in the future zz is the hg version
> id, so versions during development of a release remain unique, even
> if they can't be readily ordered.

I'd drop the 9. part. People doing comparison on these numbers possibly
performed int() conversions first (expecting that svn revisions might
have exceeded 100,000 some day); they would have to special-case 3.3
anyway. Also, in the long run, the 2.x/3.1/3.2 copies of ast will be
gone, and we are stuck with this odd prefix.

OTOH, most people probably don't do ordering comparisons at all, but
have explicit lists of versions they support (barking if it's an
unknown version); those won't be helped by the 9. prefix at all.

> This would require changes to ast.py (to add the 9.x.y prefix) and to
> release.py (to check that the 'x.y' prefix is correct in the current
> release)

I'd synthesize x.y from patchlevel.h, in which case it would be fully
automatic again.

--
nosy: +loewis
title: Change ast.__version__ calculation to provide consistent ordering -> 
Change ast.__version__ calculation  to provide consistent ordering

___
Python tracker 

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

[issue12268] file readline, readlines & readall methods can lose data on EINTR

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +pitrou

___
Python tracker 

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

[issue12273] Change ast.__version__ calculation to provide consistent ordering

[Nick Coghlan]

New submission from Nick Coghlan :

Benjamin's AST modification checkins switched directly from the SVN revision 
number (as a string) to the hg revision hash.

While that preserves uniqueness, it makes ordering difficult to determine.

The last AST version in 3.2 was '82163' (and it was '82160' in 2.7).

I would like to change the version number calculation to something like:

  '9.x.y.zzz'

where

  9 is a prefix to get 3.3+ ast.__version__ values to sort higher than earlier 
versions
  x.y is the Python version so later versions sort higher than earlier versions 
in the future
  zz is the hg version id, so versions during development of a release 
remain unique, even if they can't be readily ordered.

This would require changes to ast.py (to add the 9.x.y prefix) and to 
release.py (to check that the 'x.y' prefix is correct in the current release)

--
assignee: ncoghlan
components: Library (Lib)
messages: 137786
nosy: benjamin.peterson, brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: Change ast.__version__ calculation to provide consistent ordering
versions: Python 3.3

___
Python tracker 

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

[issue11549] Rewrite peephole to work on AST

[Nick Coghlan]

Nick Coghlan  added the comment:

Eugene raised the question of AST changes on python-dev [1] and the verdict was 
that so long as ast.__version__ is updated, AST clients will be able to cope 
with changes.

Benjamin Peterson made some subsequent changes to the AST (bringing the AST for 
try and with statements more in line with the concrete syntax, allowing 
source-to-source transforms to retain the original code structure).

This patch will probably need to be updated to be based on the latest version 
of the AST - I would be surprised if it applied cleanly to the current tip.

[1] http://mail.python.org/pipermail/python-dev/2011-April/110399.html

--

___
Python tracker 

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

[issue11690] Devguide: Add "communication" FAQ

[Nick Coghlan]

Nick Coghlan  added the comment:

On a related note, http://docs.python.org/devguide/docquality.html should 
mention that the devguide itself lives in a different repo but the process is 
otherwise similar to contributing to the main docs.

--

___
Python tracker 

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Brett Cannon]

Brett Cannon  added the comment:

Sure, but I'm not even sure it's worth the hassle of dealing with the merge. If 
you want to put in the time then that's fine, but I don't think it's worth it.

--

___
Python tracker 

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

[issue12232] embedded python import cmath

[Terry J. Reedy]

Changes by Terry J. Reedy :


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

[issue11802] filecmp.cmp needs a documented way to clear cache

[Nadeem Vawda]

Nadeem Vawda  added the comment:

> Also, I want to take a fresh look at the cache strategy (saving diffs
> of two files vs saving file contents individually) and think about
> whether than makes any sense at all for real world use cases
> (is there a common need to compare the same file pairs over and over
> again or is the typical use the comparison of many different file
> pairs).   There may even be a better way to approach the underlying
> problem using hashes of entire files (md5, sha1, etc).

I like that idea. A hash-based approach could speed up the detection of
non-equal files quite a bit.

--

___
Python tracker 

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

[issue10405] IDLE breakpoint facility undocumented

[Nick ODell]

Nick ODell  added the comment:

I've added a short note regarding breakpoints in Doc/library/idle.rst

Ned, I'm not an experienced user with IDLE by any means, but I think some 
documentation is better than none, no?

--
nosy: +Nick.ODell
Added file: http://bugs.python.org/file22268/idle.rst

___
Python tracker 

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

[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

[R. David Murray]

R. David Murray  added the comment:

Why was this issue set to pending?  No motivating comment was added.

--
nosy: +r.david.murray
status: pending -> open

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Stefan Krah wrote:
> > 
> > Stefan Krah  added the comment:
> > 
> > Marc-Andre Lemburg  wrote:
>> >> Wouldn't it be better to have distutils tell the user about the
>> >> possible options, instead of guessing and then possibly compiling
>> >> extensions which later on don't import or import, but don't work
>> >> as expected ?
> > 
> > That would be an option, yes.
> > 
> > 
>> >> Regarding the latest patch: This is not the right approach, since
>> >> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
>> >> file and not an architecture specific setup file. It is later
>> >> called with the arch identifier, which the arch specific setup files
>> >> don't check or use.
> > 
> > The patch does not change anything for Visual Studio Pro. In Visual Studio
> > Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
> > files have to be used (they also work with a superfluous parameter).

I guess what I wanted to say is that find_vcvarsall() should
return None for VC Express and code using it should then
revert to using a new find_vcvars() function, which takes the
architecture as parameter and returns the path to the correct
architecture setup file.

Hacking the support into find_vcvarsall() is not the right
approach. You have to add this support one level further up.

>> >> Also note that vcvarsall.bat can take these options:
>> >>
>> >>x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64
>> >>
>> >> The x86_* options setup the cross compilers.
> > 
> > I think the patch covers all architecture specific files that are
> > present in the Visual Studio Express + SDK setup.

Right, but it doesn't cover the ones available in VS Pro (see
above), which it should for completeness.

> > Visual Studio Pro is protected from all changes by checking for
> > the presence of the file bin\amd64\vcvarsamd64.bat. This
> > could probably be done more elegantly by using some obscure
> > registry value.
> > 
> > 
> > 
> > As Thorsten mentioned, another option would be to copy bin\vcvars64.bat
> > to bin\amd64\vcvarsamd64.bat if the latter is not present.
> > 
> > This is harmless, but it is perhaps not really the business of Python
> > to mess with existing installs.

Not a good idea :-)

PS: Changing the title, since I keep getting the following error messages from 
the email interface:

There were problems handling your subject line argument list:
- not of form [arg=value,value,...;arg=value,value,...]

Subject was: "Re: [issue7511] msvc9compiler.py: ValueError: [u'path']"

--
title: msvc9compiler.py: ValueError: [u'path'] -> msvc9compiler.py: ValueError 
when trying to compile with VC Express

___
Python tracker 

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

[issue12272] Python 2.7.1 version conflict for package "Tcl" on Windows 7

[Jack Eisenbach]

New submission from Jack Eisenbach :

I wrote a Tkinter application that runs fine with Python 2.6.5 and 2.6.6 on a 
Windows 7 (32-bit version) machine. The same app fails with 2.7.1. Below is the 
debug output:

c:\ISS\ledmatrix>led-display.py
Traceback (most recent call last):
  File "ledmatrix.py", line 2263, in 
LEDMatrix()
  File "ledmatrix.py", line 1427, in LEDMatrix
root = Tk()
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1643, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive, 
wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
{C:\Python27\tcl\tcl8.5} C:/Python26/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 
C:/library C:/library C:/tcl8.5.8/library C:/tcl8.5.8/library

C:/Python27/tcl/tcl8.5/init.tcl: version conflict for package "Tcl": have 
8.5.8, need exactly 8.5.2
version conflict for package "Tcl": have 8.5.8, need exactly 8.5.2
while executing
"package require -exact Tcl 8.5.2"
(file "C:/Python27/tcl/tcl8.5/init.tcl" line 20)
invoked from within
"source C:/Python27/tcl/tcl8.5/init.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $tclfile]"


This probably means that Tcl wasn't installed properly.

--
components: Tkinter
messages: 137778
nosy: jackie3
priority: normal
severity: normal
status: open
title: Python 2.7.1 version conflict for package "Tcl" on Windows 7
type: crash
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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[mike bayer]

mike bayer  added the comment:

> I think it's fair to ask the user to setup the environment correctly
before running "python setup.py install"

We're supporting automatic fallback to non-C install for those environments 
that don't support it.   We're just looking for a predictable CCompilerError to 
be raised for conditions like this rather than a ValueError where we have to 
parse the string message.

--

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Stefan Krah]

Stefan Krah  added the comment:

Marc-Andre Lemburg  wrote:
> Wouldn't it be better to have distutils tell the user about the
> possible options, instead of guessing and then possibly compiling
> extensions which later on don't import or import, but don't work
> as expected ?

That would be an option, yes.


> Regarding the latest patch: This is not the right approach, since
> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
> file and not an architecture specific setup file. It is later
> called with the arch identifier, which the arch specific setup files
> don't check or use.

The patch does not change anything for Visual Studio Pro. In Visual Studio
Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
files have to be used (they also work with a superfluous parameter).


> Also note that vcvarsall.bat can take these options:
>
>x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64
>
> The x86_* options setup the cross compilers.

I think the patch covers all architecture specific files that are
present in the Visual Studio Express + SDK setup.

Visual Studio Pro is protected from all changes by checking for
the presence of the file bin\amd64\vcvarsamd64.bat. This
could probably be done more elegantly by using some obscure
registry value.



As Thorsten mentioned, another option would be to copy bin\vcvars64.bat
to bin\amd64\vcvarsamd64.bat if the latter is not present.

This is harmless, but it is perhaps not really the business of Python
to mess with existing installs.

--

___
Python tracker 

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

[issue11802] filecmp.cmp needs a documented way to clear cache

[Raymond Hettinger]

Raymond Hettinger  added the comment:

We will do something.  The next release isn't for a while, so there is time to 
put thought into it rather than making an immediate check-in.

--

___
Python tracker 

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

[issue11802] filecmp.cmp needs a documented way to clear cache

[jeff deifik]

jeff deifik  added the comment:

There are many possible solutions to this problem.
Personally, I think mine is the simplest, though it changes the API.

However, there have been several suggestions on simple fixes that don't change 
the API, all of which fix the resource leak.

Doing nothing will not fix the resource leak.

How about a simple fix right now, using a lru cache, fixing all versions of 
Python, and perhaps come up with a superior solution at a later date?

--

___
Python tracker 

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

[issue11802] filecmp.cmp needs a documented way to clear cache

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Nadeem, I want to review this but won't have a chance to do it right away.  
Offhand, it seems like we could use the existing functools.lru_cache() for this 
if the stats were included as part of the key:  cache[f1, f2, s1, s2]=outcome.

Also, I want to take a fresh look at the cache strategy (saving diffs of two 
files vs saving file contents individually) and think about whether than makes 
any sense at all for real world use cases (is there a common need to compare 
the same file pairs over and over again or is the typical use the comparison of 
many different file pairs).   There may even be a better way to approach the 
underlying problem using hashes of entire files (md5, sha1, etc).

--
assignee: nadeem.vawda -> rhettinger
resolution:  -> later

___
Python tracker 

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

[issue12232] embedded python import cmath

[Mark Dickinson]

Mark Dickinson  added the comment:

Looking at the cmath source, I'd be a bit suspicious that either the Py_NAN or 
the Py_HUGE_VAL macro (or both) is triggering an FPE.  Both those values are 
used during module initialization.

--

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Ryan Seto]

Changes by Ryan Seto :


--
nosy:  -MrWerewolf

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

mike bayer wrote:
> > 
> > mike bayer  added the comment:
> > 
> > regarding "hey this is an MS bug not Python", projects which feature 
> > optional C extensions are starting to apply workarounds for the issue on 
> > their end (I will need to commit a specific catch for this to SQLAlchemy) - 
> > users need to install our software and we need to detect compilation 
> > failures as a sign to move on without it.   I think it's preferable for 
> > Python distutils to work around an MS issue rather than N projects having 
> > to work around an MS issue exposed through distutils.  Seems like this bug 
> > has been out there a real long time...bump ?
This is not really an MS issue. Setting up the environment to be
able to compile extensions is a prerequisite on most platforms and
with most compilers.

MS VC++ supports having multiple compiler versions on the same
machine and allow compiling to x86, x64 and ia64 (at least
in more recent VC++ versions).

I think it's fair to ask the user to setup the environment correctly
before running "python setup.py install", since distutils doesn't
really know which compiler to use - e.g. you could be cross-compiling
for x64 on an x86 machine, or you may want to use VC 2008 instead of
a more recently installed VC 2010.

Wouldn't it be better to have distutils tell the user about the
possible options, instead of guessing and then possibly compiling
extensions which later on don't import or import, but don't work
as expected ?

Regarding the latest patch: This is not the right approach, since
find_vcvarsall() is supposed to return the path to the vcvarsall.bat
file and not an architecture specific setup file. It is later
called with the arch identifier, which the arch specific setup files
don't check or use.

Also note that vcvarsall.bat can take these options:

   x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64

The x86_* options setup the cross compilers.

--
nosy: +lemburg

___
Python tracker 

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

[issue12232] embedded python import cmath

[Mark Dickinson]

Mark Dickinson  added the comment:

> Is it possible that the problem is related to floating point exceptions?

Hmm.  It's possible, but it's still a bit surprising that the crash occurs at 
import time rather than when calling one of the cmath functions.  But it's very 
possible that there are some missing PyFPE_START_PROTECT macros in the cmath 
source.

BTW, if the problem *is* in cmath, it's likely to also occur with Python 2.7:  
that module changed very little between 2.6 and 2.7.

--

___
Python tracker 

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

[issue12232] embedded python import cmath

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Is it possible that the problem is related to floating point exceptions?
A quick Google search showed similar issue in another embedded library:
http://www.softintegration.com/support/faq/embed.html#borland

It seems important to add this instruction:
   _control87(MCW_EM, MCW_EM);
Can you try and modify your program accordingly?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue12246] Warn when trying to install third-party module from an uninstalled checkout

[Tshepang Lekhonkhobe]

Tshepang Lekhonkhobe  added the comment:

Find attached.

--
Added file: http://bugs.python.org/file22267/display-warning_try2.diff

___
Python tracker 

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

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, the dependencies are now committed. Here is a new patch addressing 
Charles-François' comments: select() is now called before each call to read() 
when sentinels are given, to avoid race conditions.

--
stage:  -> patch review
Added file: http://bugs.python.org/file22266/sentinels5.patch

___
Python tracker 

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

[issue10115] Support accept4() for atomic setting of flags at socket creation

[Charles-François Natali]

Charles-François Natali  added the comment:

@nvetoshkin
Could you update your patch against py3k?

I've got a couple comments (can't login to Rietveld, it's probably due to the 
change of my tracker account name):

if(flags & ~(SOCK_NONBLOCK | SOCK_CLOEXEC)) {
PyErr_SetString(PyExc_ValueError,
"Wrong flag value");
return NULL;
}

I'm not sure that's necessary:
- accept4() can sanitize its input itself if necessary (will fail with EINVAL)
- if some flag is added, or another OS doesn't use the same flags, it'll fall 
out of sync


#ifdef HAVE_ACCEPT4
 /* These flags are not inherited after accept */
 type &= ~(SOCK_NONBLOCK & SOCK_CLOEXEC);
#endif /* HAVE_ACCEPT4 */

SOCK_NONBLOCK & SOCK_CLOEXEC == 0, so this doesn't do much.
Second, you should probably reuse what's done in Lib/socket.py for timeout 
inheritance upon accept (except that here you certainly don't want to set the 
socket to blocking if SOCK_NONBLOCK flag is passed).

You should add a test for that: have a look at test_pipe2 in 
Lib/test/test_posix.py.

--

___
Python tracker 

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

[issue12021] mmap.read requires an argument

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Didn't you forget to attach the patch?

--

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Eli Collins]

Eli Collins  added the comment:

> What would the value be for non-C Python implementations?

I'm not really sure how this idea could have any value for those 
implementations, at least for the ones that can't make use of C extensions at 
all (I think PyPy can; so I guess that would leave Jython & IronPython). Then 
again, I don't see how anything inside "disutils2.compiler" could be relevant 
to those implementations either, so maybe I don't understand the question. 

> If the need for compiler-specific options is very common, we could
> consider either improving the compiler system or implement this
> request; if it’s not common, letting people use hooks would be enough.

I'm not entirely sure how common this is; even within those people who write C 
extensions, but I'm pretty sure some problems are unavoidable, such as 
compiler-specific options when linking to external libraries or 
compiler-specific ways of specifying compatibility options. Case in point: this 
stackoverflow question ( 
http://stackoverflow.com/questions/724664/python-distutils-how-to-get-a-compiler-that-is-going-to-be-used
 ) had a few solutions... and it seems to me that the cleanest one (from 'Jon') 
made much more sense as an environment marker. 

A similar case is this email thread ( 
http://comments.gmane.org/gmane.comp.python.devel/123768 ), which presents a 
situation where the person needs to set different options for a specific 
*version* of a compiler. In that case, the main solution people proposed was 
"see if setup() fails, and try again with different options". This is the same 
solution SQLAlchemy & SimpleJson have been using to implement "optional" c 
extensions under distutils1; and I wasn't sure if hacks like that were even 
going to be possible using the new hooks system.

Mind you, the person in that email thread needed to distinguish different 
*versions* of particular compilers, which I didn't propose in this issue - 
mainly because the compilers already have unique names assigned to them, and 
would only require making that info available; whereas gathering version 
strings and comparing them would require much more work & testing to implement 
properly.

--

___
Python tracker 

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

[issue12021] mmap.read requires an argument

[Petri Lehtinen]

Petri Lehtinen  added the comment:

> I think duplicating it is fine, since the code is probably simple anyway

Added a new patch. I duplicated the None converting logic in _io/_iomodule.c to 
mmapmodule.c, changed the doc to say "read([n])", and expanded the test cases a 
bit.

--

___
Python tracker 

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

[issue12271] Python 2.7.x on IA64 running SLES 11 SP1

[Vincent]

Vincent  added the comment:

Hello Stefan,

Thanks a lot for your time and answer, but here are some additional information 
regarding the requires "panel.h" file. I've just launched a find command onto 
my ia64 server, and here is the result:

hesione:/ # find / -name "panel.h"
/usr/include/ncurses/panel.h
/usr/include/ncurses6/ncurses/panel.h
/usr/include/ncurses6/ncursesw/panel.h
/usr/include/ncursesw/panel.h
/usr/src/linux-2.6.32.12-0.7-obj/ia64/default/include/config/panel.h

As you may have also observed, the build command is claiming also ncurses, 
which is installed.

hesione:~ # rpm -qa|grep ncurses
yast2-ncurses-pkg-2.17.16-0.1.77
libncurses6-5.6-90.55
ncurses-devel-5.6-90.55
libncurses5-5.6-90.55
yast2-ncurses-2.17.17-0.4.38
ncurses-utils-5.6-90.55
libncurses5-x86-5.6-90.55
libncurses6-x86-5.6-90.55

Any further information will be welcome.

Thanks again for your patience, time and answer.

All the best,

Vincent

--
status: pending -> open

___
Python tracker 

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

[issue12196] add pipe2() to the os module

[Roundup Robot]

Roundup Robot  added the comment:

New changeset ba975c7c33d3 by Charles-François Natali in branch 'default':
Issue #12196: Make os.pipe2() flags argument mandatory.
http://hg.python.org/cpython/rev/ba975c7c33d3

--

___
Python tracker 

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

[issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on Pipe()

[Alexander Myodov]

Alexander Myodov  added the comment:

Sorry for being a little bit slow to respond...
No I was not able to come up with a testcase that could generate this problem 
in a reproducible way on any Windows box I had. This problem sometimes occured 
on various OS versions, being probably a Windows oof configuration problem 
rather than the problem of the Python code itself. Nevertheless, changing it as 
I described above didn't cause any adverse side effects, at least for me.

--

___
Python tracker 

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

[issue12232] embedded python import cmath

[Thanh Ly]

Thanh Ly  added the comment:

Hi Terry

With BB 6 I import python26.dll and embed and extend Python in the same 
project (sent) fairly successfully. I converted the DLL to a BB format lib 
file and manage to extend Python successfully but could not link when trying 
to embed Python with the Lib file.

I would like to try with 2.7 and 3.1 however, I'm hard against it, time wise 
and not sure when I can verify the issue.

I did manage to try with 2.4 (as lib file was readily available for BB) and 
it worked.

Thank you for your advice and recommendations.

Thanh.

--

___
Python tracker 

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

[issue12040] Expose a Process.sentinel property (and fix polling loop in Process.join())

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue12040] Expose a Process.sentinel property (and fix polling loop in Process.join())

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 568a3ba088e4 by Antoine Pitrou in branch 'default':
Issue #12040: Expose a new attribute `sentinel` on instances of
http://hg.python.org/cpython/rev/568a3ba088e4

--
nosy: +python-dev

___
Python tracker 

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

[issue11893] Obsolete SSLFakeFile in smtplib?

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue11893] Obsolete SSLFakeFile in smtplib?

[Roundup Robot]

Roundup Robot  added the comment:

New changeset b68390b6dbfd by Antoine Pitrou in branch 'default':
Issue #11893: Remove obsolete internal wrapper class `SSLFakeFile` in the 
smtplib module.
http://hg.python.org/cpython/rev/b68390b6dbfd

--
nosy: +python-dev

___
Python tracker 

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

[issue11893] Obsolete SSLFakeFile in smtplib?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Note that I didn't test LMTP. Should I or is it obvious enough that the 
> change is ok?

Thank you for the patch! I think it's ok. I'll give it a try and commit
if everything is alright.

--

___
Python tracker 

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

[issue12196] add pipe2() to the os module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Hmm, thinking about it, I don't see any reason to make the flags argument 
> optional.
> Here's a patch changing that (also, pipe2 is now declared as METH_O instead 
> of METH_VARARGS).

Looks good to me.

--

___
Python tracker 

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

[issue12271] Python 2.7.x on IA64 running SLES 11 SP1

[Stefan Krah]

Stefan Krah  added the comment:

panel.h is not found. You'll need to install the package that
provides libpanel together with the header files:

error: panel.h: No such file or directory


This does not look like a Python bug, so I'll set the issue to
'pending'. You can still respond to the issue if you think otherwise.

--
nosy: +skrah
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending

___
Python tracker 

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

[issue12238] Readline module loading in interactive mode

[R. David Murray]

R. David Murray  added the comment:

I've done a little poking around, and it looks like you are correct and I'm 
wrong. It appears that readline.so is or should be a special case.  I've added 
some people to nosy to see what they think.

Specifically, it appears that if I put a file that should shadow a library 
module that is imported at python startup time (eg: os.py) into my current 
working directory I still get the os.py from the appropriate lib directory, 
even though '' is first in my sys.path.  This is not how I thought it worked, 
but it is my observation.  I tested this on 2.6.6, 2.7.1 and 3.3 tip.

--
nosy: +brett.cannon, haypo, pitrou
versions: +Python 2.7, Python 3.1, 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

[issue12196] add pipe2() to the os module

[Charles-François Natali]

Charles-François Natali  added the comment:

Hmm, thinking about it, I don't see any reason to make the flags argument 
optional.
Here's a patch changing that (also, pipe2 is now declared as METH_O instead of 
METH_VARARGS).

--
Added file: http://bugs.python.org/file22265/pipe2_arg.diff

___
Python tracker 

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

[issue12240] Allow multiple setup_hooks

[Erik Bray]

Erik Bray  added the comment:

Adds support for multiple setup_hooks and updates the docs.

For now I left the option name as "setup_hook", though it might make sense to 
rename it to "setup_hooks" for consistency's sake.

--
keywords: +patch
Added file: http://bugs.python.org/file22264/python_issue12240.patch

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Stefan Krah]

Stefan Krah  added the comment:

Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to
be supportive of the patch.


Re DISTUTILS_USE_SDK:

I don't think many users are aware of this variable. Also, it is not
needed at all; it is sufficient to execute vcvars64.bat manually
before running setup.py.

--

___
Python tracker 

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

[issue8668] Packaging: add a 'develop' command

[Éric Araujo]

Changes by Éric Araujo :


--
assignee: tarek -> eric.araujo
keywords: +gsoc
title: add a 'develop' command -> Packaging: add a 'develop' command
versions: +Python 3.3 -3rd party

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Éric Araujo]

Éric Araujo  added the comment:

What would the value be for non-C Python implementations?

If the need for compiler-specific options is very common, we could consider 
either improving the compiler system or implement this request; if it’s not 
common, letting people use hooks would be enough.

--
versions: +Python 3.3

___
Python tracker 

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

[issue12222] All pysetup commands should respect exit codes

[Éric Araujo]

Changes by Éric Araujo :


--
dependencies: +pysetup --search should return non-zero when a dist is not 
installed and print a message stating the fact.

___
Python tracker 

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

[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

[Éric Araujo]

Changes by Éric Araujo :


--
status: open -> pending

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError: [u'path']

[Éric Araujo]

Éric Araujo  added the comment:

Thorsten Behrens said:
> You are right, this is not a bug in Python. The diff provides a
> workaround for a limitation in VC++ 2008 Express. This diff is a
> piece of user service.

ipatrol added:
> Purity shmurity. The point of distutils is largely to present a
> unified and simple interface. 'python setup.py install' should be all
> a user has to do on any platform. Unless you can come up with a
> better idea, MSVC is really the only big compiler on Windows.

The feature freeze is distutils is not a conspiracy plotted by developers 
loving purity; it is a necessity caused by hard pragmatism.  Tarek would have 
loved to continue improving distutils instead of forking distutils2, but he 
could not because third-party code relying on bugs and workarounds was broken.  
We have to be cautious, and it has nothing to do with purity.  Believe me, the 
freeze, fork and merge was not something fun for distutils developers, but we 
had to do it precisely for our users.

While I agree that in an ideal world, “'python setup.py install' should be all 
a user has to do on any platform”, it cannot be done in distutils.  Like Martin 
said:
> if you want to use SDK tools, you are supposed to set
> DISTUTILS_USE_SDK, after opening the respective build environment

For distutils2/packaging however, we can work on improving the compiler system, 
so that “pysetup run install” is all a user had to do on any platform.  See 
#12257 for that.

--

___
Python tracker 

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

[issue12226] use secured channel for uploading packages to pypi

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

On Mon, Jun 6, 2011 at 11:50 AM, Éric Araujo  wrote:
> If you make an HTTPS connection without checking the certificate, what 
> security does it add?

I'm in favor of cert checking, myself.

--

___
Python tracker 

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

[issue12246] Warn when trying to install third-party module from an uninstalled checkout

[Éric Araujo]

Éric Araujo  added the comment:

Thanks.  What about using sysconfig.is_python_build in your patch?

--
assignee: tarek -> eric.araujo
title: create installation path if it's non-existent -> Warn when trying to 
install third-party module from an uninstalled checkout

___
Python tracker 

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

[issue12226] use secured channel for uploading packages to pypi

[Éric Araujo]

Éric Araujo  added the comment:

>> Thanks Stephan, that was on my mind but I forgot it.  I’m -1 on
>> using https if no validation is performed.
> It will be more professional if you could also explain why.

If you make an HTTPS connection without checking the certificate, what security 
does it add?

> > Not really; it’s an explanation of our release rules, exposed by
>> one of the older developers.
> Release rules should be clear enough not to require explanation.

Explanations make them clear.

> Any account on PyPI that uploads packages used for in enterprise
> deployment schemes imposes a danger.

Sidenote: I don’t want to give less security to non-enterprise users.

Anyway, I understand your point now: insecure upload and download are 
vulnerable to MITM attacks, and encouraging HTTPS use (through default value + 
docs) would help against that.  I am supportive of a patch, but it doesn’t mean 
the release process should not be followed.  See also #11357 and #8561 about 
download security.

--

___
Python tracker 

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

[issue10884] pkgutil EggInfoDistribution requirements for .egg-info metadata

[Éric Araujo]

Éric Araujo  added the comment:

Can you check if this is covered in test_database?

--

___
Python tracker 

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Éric Araujo]

Éric Araujo  added the comment:

Is this minor cleanup, non-bugfix okay for 3.2?

--

___
Python tracker 

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

[issue12218] Removing wsgiref.egg-info

[Roundup Robot]

Roundup Robot  added the comment:

New changeset cc28bc86d474 by Éric Araujo in branch 'default':
Remove wsgiref.egg-info from msi.py (follow-up to d615eb7bce33, #12218)
http://hg.python.org/cpython/rev/cc28bc86d474

--

___
Python tracker 

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

[issue12238] Readline module loading in interactive mode

[Niels Heinen]

Niels Heinen  added the comment:

Hi Eric, David,

This means that you cannot type "python" and press  in any shared 
directory without the risk of a malicious readlinemodule.so being imported and 
executed.  

I think this is different from a scenario where someone explicitly runs a 
script or imports a module in interactive mode where it is also reasonable that 
such a person understands the importing mechanism.

Thanks for the quick responses btw!

Niels

--

___
Python tracker 

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

[issue12021] mmap.read requires an argument

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If being pretty is the only reason for this choice, then I think that
> documenting the method as
> 
> method:: read([n])
> 
> is simpler and cleaner .
> 
> But you've got much more experience than me, so I won't argue any further :-)

There are contexts where it is easier to give the default argument than
call the method without argument, though, and that's where I find None
more intuitive than -1 :) Arguably it's not very important, though.

> > Can I use _PyIO_ConvertSsize_t? Or should I duplicate its
> > functionality in mmapmodule.c?
> 
> I let Antoine answer that.

I'm not sure. This would require including iomodule.h, which is supposed
to be private to the _io module. I think duplicating it is fine, since
the code is probably simple anyway (I'm too lazy to take a look right
now :-)).

--

___
Python tracker 

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

[issue12021] mmap.read requires an argument

[Charles-François Natali]

Charles-François Natali  added the comment:

>> That's because of the _PyIO_ConvertSsize_t converter, which silently
>> converts None to -1.
>> There's probably a good reason for doing this in the _io module
>
> I'm not sure about the original reason, but I find None as the default 
> "omitted" value prettier than -1 myself, so I think it's a good thing :)
>

If being pretty is the only reason for this choice, then I think that
documenting the method as

method:: read([n])

is simpler and cleaner .

But you've got much more experience than me, so I won't argue any further :-)

> Can I use _PyIO_ConvertSsize_t? Or should I duplicate its
> functionality in mmapmodule.c?

I let Antoine answer that.

--

___
Python tracker 

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

[issue12270] Please update copyright notice on bugs.python.org to 2011?

[Ezio Melotti]

Ezio Melotti  added the comment:

Done in r88853, thanks for the report!

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

[issue12270] Please update copyright notice on bugs.python.org to 2011?

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee:  -> ezio.melotti
nosy: +ezio.melotti

___
Python tracker 

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

[issue12271] Python 2.7.x on IA64 running SLES 11 SP1

[Vincent]

New submission from Vincent :

Hello everybody,

With the same build/compile command, I'm able to have "my" runing python 
version (2.6.x or 2.7.x) on IA64 server runing SLES 10 SP2/SP3,not on IA64 
server runing SLES 11 SP1. I've try with 2.7, 2.7.1 and 2.7.2rc1 version 
without success.

On both configuration types, I've installed all the available libraries, but on 
SLES 11 SP1, the make resulting message is the following (the complete building 
messages are in the joined gzip text file):

--
...
Python build finished, but the necessary bits to build these modules were not 
found:
_bsddb _sqlite3   _ssl
_tkinter   bsddb185   bz2 
dl imageopreadline
sunaudiodevzlib   
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.


Failed to build these modules:
_curses_panel 

running build_scripts
--

Any advice will be welcome.

Thanks a lot for your attention and your process.

All the best,

Vincent

--
components: Build
files: Building_error_SLES11SP1_ia64.txt.gz
messages: 137737
nosy: v.clau...@free.fr
priority: normal
severity: normal
status: open
title: Python 2.7.x on IA64 running SLES 11 SP1
type: compile error
versions: Python 2.7
Added file: 
http://bugs.python.org/file22263/Building_error_SLES11SP1_ia64.txt.gz

___
Python tracker 

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

[issue12270] Please update copyright notice on bugs.python.org to 2011?

[AJ]

New submission from AJ :

We are almost in mid-year. :)

http://bugs.python.org/ has a copyright notice "1990-2010". Please update it to 
include 2011.

--
components: None
messages: 137736
nosy: brandmyself
priority: normal
severity: normal
status: open
title: Please update copyright notice on bugs.python.org to 2011?

___
Python tracker 

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

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

[Aron Griffis]

Changes by Aron Griffis :


--
nosy: +agriffis

___
Python tracker 

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

[issue10376] ZipFile unzip is unbuffered

[Xuanji Li]

Changes by Xuanji Li :


--
nosy: +xuanji

___
Python tracker 

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

[issue12170] Bytes.index() and bytes.count() should accept byte ints

[Xuanji Li]

Changes by Xuanji Li :


--
nosy: +xuanji

___
Python tracker 

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

[issue12226] use secured channel for uploading packages to pypi

[anatoly techtonik]

anatoly techtonik  added the comment:

On Sat, Jun 4, 2011 at 5:33 PM, Éric Araujo  wrote:>
>> I think there should be a warning that the connection is
>> unauthenticated (i.e. not secure). Users tend to be upset if they see
>> 'https' and later find out that no certificates were verified.
>
> Thanks Stephan, that was on my mind but I forgot it.  I’m -1 on using https 
> if no validation is performed.

It will be more professional if you could also explain why. Thanks.

>> I believe that's a very personal judgement.
> Not really; it’s an explanation of our release rules, exposed by one of the 
> older developers.

Release rules should be clear enough not to require explanation.

>> For me exposing core Python development accounts is a fundamental
>> flaw.

> What is a core Python development account?

'core' is not the best word here, so it needs an explanation. Any
account on PyPI that uploads packages used for in enterprise
deployment schemes imposes a danger. Potential target are identified
using 'popularity package/developer activity' rating to reduce the
risk. These are the primary targets for an attack, which I called
'core'. 'primary' would be a better name probably.

--

___
Python tracker 

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

[issue12268] file readline, readlines & readall methods can lose data on EINTR

[Gregory P. Smith]

Changes by Gregory P. Smith :


Removed file: 
http://bugs.python.org/file22261/test_fileio_readers_3.2-gps01.diff

___
Python tracker 

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

[issue12268] file readline, readlines & readall methods can lose data on EINTR

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I haven't looked beyond the reading methods it is possible that some of the 
write implementations have a similar issue.  Patch gps02 for 3.2 attached.

I'll use that as the basis for a stand alone test_file_eintr.py targeted at 2.7.

--
Added file: http://bugs.python.org/file22262/test_and_fix_readers_3.2-gps02.diff

___
Python tracker 

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