[issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT"

[Ned Deily]

Ned Deily added the comment:

After spending some time investigating this issue, I believe that potential 
upgrade compatibility issues have been introduced by the changes for 
Issue13169.  How critical they are and, in particular, whether they violate our 
implicit promises of maintenance (point) release compatibility are questions 
for discussion.

The signature of the problem is "ImportError: cannot import name MAXREPEAT" as 
a result of an attempt to import re or a module that itself imports re:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/nad/issue18050/u/lib/python2.7/re.py", line 105, in 
import sre_compile
  File "/home/nad/issue18050/u/lib/python2.7/sre_compile.py", line 14, in 

import sre_parse
  File "/home/nad/issue18050/u/lib/python2.7/sre_parse.py", line 17, in 
from sre_constants import *
  File "/home/nad/issue18050/u/lib/python2.7/sre_constants.py", line 18, in 

from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT

The changes for Issue13169 moved the definition of MAXREPEAT into C code and 
then added an import of the new C constant into Lib/sre_constants.py to 
continue to provide sre_constants.MAXREPEAT for third-party modules that have 
been using it.  As long as the versions of the Python interpreter and the 
standard library Python files (sys.prefix/lib/pythonX.Y) remain in sync, there 
is not a problem.  However, if a situation arises where a pre-13169 interpreter 
is used with a post-13169 standard library, the "cannot import name MAXREPEAT" 
ImportError will occur.  I have found at least two situations where this can 
happen:

1. when a C application has statically embedded a pre-13169 interpreter and the 
standard library pointed to by its sys.prefix gets upgraded to a post-13169 
version.  The interpreter then crashes during initialization in Lib/site.py 
which imports re in both Python 2 and 3 (for different purposes).

2. when a virtualenv created with a pre-13169 non-shared interpreter is used 
with an upgraded post-13169 standard library.  In this case, the interpreter 
makes it past initialization because virtualenv (at least, the current version) 
creates a modified site.py in the virtualenv lib/pythonX.Y that happens to not 
import re.  However, the import error will occur on the first use of re.  Side 
note: 3.3 standard library pyvenv does not seem to have this problem since the 
created venv symlinks to the sys.prefix interpreter and libs rather than 
copying it, like virtualenv does.

Note that Pythons built with --enable-shared (or --enable-framework on OS X) 
generally will not have a problem as long as the shared libpythonX.Y and the 
standard library remain consistent.  That is, in both cases above, a Python 
upgrade will automatically cause both the embedded app and the virtualenv to 
run with the newer interpreter.  AFAICT, the problems will only be seen when 
using a non-shared Python.

I believe the upgrades affected by this problem are:

2.7 through 2.7.3 upgraded to 2.7.4 or 2.7.5
3.3.0 upgraded to 3.3.1 or 3.3.2
3.2 through 3.2.3 upgraded to 3.2.4 or 3.2.5 (unverified)

The problem should be fixable by applying a patch along the lines suggested by 
Samuel.  Regardless of whether this is a compatibility break or not, I think we 
should fix the problem because people are already running into it.  (Nosying 
the release managers for their input.)

While related, the root cause of the vim problem reported above is probably 
more complicated because, although it appears to embed a Python interpreter, 
the standard library used by the OS X system vim appears to depend on $PATH, 
apparently incorrect behavior in vim.  Unfortunately, OS X vim users on 10.8 
(probably also on 10.7) may encounter this problem when they try to use :py if 
they install an updated version of Python 2.7, such as from python.org or a 
third-party distributor like Homebrew or MacPorts.  And, when vim crashes due 
to the import error, it leaves the terminal settings in an unusable state.  One 
user workaround might be to create a shell function or alias to tweak PATH 
before using vim to ensure /usr/bin/python2.7 is found first.  Or simply patch 
re.py in the upgraded Python.

--
components: +Library (Lib) -Extension Modules
nosy: +benjamin.peterson, georg.brandl, serhiy.storchaka
priority: normal -> high
stage:  -> needs patch
title: _sre.MAXREPEAT not defined in 2.7.3 -> embedded interpreter or 
virtualenv fails with "ImportError: cannot import name MAXREPEAT"
versions: +Python 3.3, Python 3.4

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Nick Coghlan]

Nick Coghlan added the comment:

Somewhat related, I *know* you've read type.__new__. Compared to that, 
enum.EnumMeta.__new__ is still pretty straightforward ;)

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Nick Coghlan]

Nick Coghlan added the comment:

Eli, remember that TOOWTDI stands for "There's one *obvious* way to do it" 
rather than "There's *only* one way to do it". The latter interpretation leads 
to insanely complex APIs that attempt to solve everyone's problems, while the 
former favours 80% solutions that cover most use cases, with extension hooks 
that let people handle the other 20% as they see fit.

The point of the enum standardisation is to have a conventional way that enums 
*behave*, and then allow variations on that theme for those cases where the 
stdlib implementation is "close, but not quite what I need or want".

The whole metaclass machinery is built around this concept of letting people 
create domain specific behaviour, that is still somewhat unified due to 
conventions like the descriptor protocol. You can do a *lot* with just 
descriptors, so if you don't need a custom metaclass, you shouldn't use one.

PEP 422's class initialisation hook is aimed specifically at certain cases that 
currently need a metaclass and providing a simpler way to do them that lets you 
just use "type" as the metaclass instead.

It's the same with enums - if you don't need to customise the metaclass, you 
shouldn't. But there are some use cases (such as syncing the Python level enum 
definition with a database level one) where additional customisation will be 
needed. We also want to give people the freedom they need to experiment with 
different forms of definition time syntactic sugar to see if they can come up 
with one we like enough to add to the standard library in 3.5.

Does documenting these definition time extension points constrain what we're 
allowed to do in the future? Yes, it does. But, at the same time, it takes a 
lot of pressure off us to add more features to the standard enum type over time 
- if people have niche use cases that aren't handled well by the standard 
solution (and we already know they do), we can point them at the supported 
extension interface and say "go for it". For the majority of users though, the 
standard enum type will work fine, just as ordinary classes are adequate for 
the vast majority of object oriented code.

--

___
Python tracker 

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

[issue2053] IDLE - standardize dialogs

[Todd Rovito]

Changes by Todd Rovito :


--
nosy: +Todd.Rovito

___
Python tracker 

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

[issue15392] Create a unittest framework for IDLE

[Todd Rovito]

Todd Rovito added the comment:

Patch does indeed apply and I get good results!  The patch is well done and 
provides a nice example on how to write unit tests.
+1 for making the commit from me

R. David Murray you used the patch command while I used "hg import --no-commit 
mywork.patch" as specified in the Python Developers Guide.  Next time I have an 
issue I will use patch and see if it works better.

--

___
Python tracker 

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

[issue5124] IDLE - pasting text doesn't delete selection

[Todd Rovito]

Todd Rovito added the comment:

I haver verified Roger's patch does indeed fix the problem on Linux CentOS 6.4 
with IDLE 3.4.

The Linux situation is complex.  Basically as I see it over the years pure X11 
applications are becoming extinct and most developers either use GTK (for 
GNOME) or QT (for KDE). I don't blame anybody for moving to one of these 
toolkits because writing a pure X11 application is painful.  In the near future 
Wayland http://en.wikipedia.org/wiki/Wayland_(display_server_protocol) will 
take over and I wonder how many X11 applications will actually be ported.  I 
agree with Roger we should try and make IDLE as consistent as possible across 
operating systems.  

+1 for applying the patch.

--

___
Python tracker 

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

[issue17511] Idle find function closes after each find operation

[Todd Rovito]

Todd Rovito added the comment:

I was wondering does it make sense to commit this patch since it is similar to 
http://bugs.python.org/issue14146 then put the issue in the pending state as we 
wait for the TK/TCL fix?  It seems more consistent to me since this issue is 
basically the same highlight problem as 14146.  I imagine this is very 
bothersome for Windows users.

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Eli Bendersky]

Eli Bendersky added the comment:

Guido, IMHO back-doors are fine in many cases, just not this one. The way I see 
it, our main goal here is to collect a bunch of custom implementations of enums 
under a single umbrella. This is not very different from what was done with 
OrderedDict and namedtuple at some point. There were probably a bunch of custom 
implementations, along with more and less commonly used recipes. At some point 
a single implementation was added to the stdlib, without (AFAICS) major 
back-doors.

Yes, the Enum case is vastly more complex than either OrderedDict or 
namedtuple, and there is a multitude of different behaviors that can be 
anticipated (as the lengthy discussions leading to the acceptance of PEP 435 
demonstrated). And yet, I was also hoping to have a single canonical 
implementation, so that people eventually accept it as "the one". Stdlib 
modules tend to win over in the long run.

The other point is that I think the implementation could be much simpler 
without having these back doors. As it stands now, the code is complex and 
hence brittle. Any change will be difficult to do because we're locked down 
very strictly by a set of intrusive and deep, yet externally "promised" 
interfaces. The same can be said, again, about OrderedDict and namedtuple, the 
code of which is very straightforward.

Maybe I'm blowing this out of proportions, maybe not. I'm not sure. As I said, 
I don't want to strongly argue about this. If both you and Nick are OK with 
keeping the customization mechanisms in, I defer to your judgment.

--

___
Python tracker 

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

[issue16278] os.rename documentation slightly inaccurate

[Todd Rovito]

Todd Rovito added the comment:

Ping!!!

I have not heard anything about this patch so I wanted to ping it to get more 
feedback.  Thanks!

--

___
Python tracker 

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

[issue5124] IDLE - pasting text doesn't delete selection

[Terry J. Reedy]

Terry J. Reedy added the comment:

I agree that the paste replace should be added as an option on linux, but 
without a broader survey of Linux Idle users to convince me otherwise, I have 
to agree that the default should stay as it is. I do not see any call to make 
the x11 behavior an option on mac and windows.

--
type: behavior -> enhancement

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Guido van Rossum]

Guido van Rossum added the comment:

Eli, what's wrong with having a backdoor?  Python is literally *full* of 
backdoors.  I have a feeling that somehow you are trying to build an Enum class 
that is unpythonic in its desire to enforce some kind of "ideal enum" behavior.

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Eli Bendersky]

Eli Bendersky added the comment:

I'm not sure which promises you're referring to Nick, and to whom they were 
made; the only formal promise we made is PEP 435 - and it doesn't mention this 
extensibility.

I won't argue beyond this comment, since I know I'm part of the minority 
opinion here. However, I still think this is a mistake.

The most important original goal of Enum (as discussed during the language 
summit) was to replace all the custom enum implementations by one that is 
standard. A far fledged extension mechanism will just make it so we'll have a 
fleet of bastardized "extended enums", each with its own capabilities, each 
different from the others. With one standard Enum, when you're reading 
someone's code and you see:

class Foo(Enum):
  ...

You know very well what Foo is. Restricted extensions like IntEnum and even 
your @enum.unique are still tolerable because they're explicit:

# enum.unique is standard and says what it is explicitly
@enum.unique
class Foo(Enum):
  ...

But if we open the gates on customization, we'll have:

class Foo(AutoEnum):
  Red, White, Black

And:

class Bar(SomeOtherAutoEnum):
  Red = ...
  White = ...
  Black = ...

And:

class Baz(SomeEvenOtherMagicEnum):
  ... # whatever goes here

And we're back to square 1, because these Enums are not standard, and each 
framework will have its own clever customization one will need to understand in 
order to read code with Enums.

Exposing and documenting the metaclass and customizations of __new__ is a whole 
coffin for the "there is only one way to do it" decision of stdlib's Enum. It 
might have been better to just define AutoNumberedEnum, BitfieldEnum and 
Magic42Enum as part of the enum package in stdlib and be over with it; but this 
was strongly rejected by others and particularly Guido during the summit and 
later. Now we're just creating a back-door to get into the same situation.

--

___
Python tracker 

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

[issue7940] re.finditer and re.findall should support negative end positions

[Matthew Barnett]

Matthew Barnett added the comment:

Like the OP, I would've expected it to handle negative indexes the way that 
strings do.

In practice, I wouldn't normally provide negative indexes; I'd use some string 
or regex method to determine the search limits, and then pass them to finditer 
and findall, so they'd be non-negative anyway.

--

___
Python tracker 

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

[issue5124] IDLE - pasting text doesn't delete selection

[Ned Deily]

Ned Deily added the comment:

Unfortunately, there is no one right answer to paste behavior on X11, unlike on 
native Windows and Mac implementations where there is essentially system-wide 
consistent paste behavior enforced by the underlying operating system.  As the 
Tk Wiki points out (and the comments hers concur), different users are going to 
have different expectations.  If we want to make this behavior available with 
X11 Tk, then it really should be a user configurable option.  Without providing 
an option, the overriding design principle is that the status quo wins a 
stalemate 
(http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html).

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Nick Coghlan]

Nick Coghlan added the comment:

Also, we know for a fact that people plan to use the customisation features
- it was making their code work that drove the current extension design.

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Nick Coghlan]

Nick Coghlan added the comment:

Supporting extensions was one of the things that got Ethan's version
through review. So -1 on going back on our promise to support those
variants. They have been reviewed and tested just as thoroughly as the rest
of the design.

--

___
Python tracker 

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

[issue5124] IDLE - pasting text doesn't delete selection

[Guilherme Simões]

Guilherme Simões added the comment:

I think IDLE should ignore general X11 practice. I used Linux for years and 
have never seen this behavior before because almost all programs behave in the 
Mac/Windows way.

--
nosy: +Guilherme.Simões

___
Python tracker 

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

[issue1693050] \w not helpful for non-Roman scripts

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
versions: +Python 3.3, Python 3.4 -Python 3.1

___
Python tracker 

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

[issue18052] IDLE 3.3.2 Windows taskbar icon regression

[Terry J. Reedy]

Terry J. Reedy added the comment:

Restarting Windows solves the issue. If nothing else, the installer could end 
with 'Restart Windows for Idle icons to work correctly'.

--

___
Python tracker 

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

[issue706406] fix bug #685846: raw_input defers signals

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Closing as fixed. I tested with python2.7 and 3.2, both with and without a 
readline module.

Behavior is consistent and looks correct to me: the signal is honored (message 
printed after 5s), and does not stop the raw_input(), except when it raises an 
exception, in which case the command exits and the exception is propagated.

--
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Eli Bendersky]

Eli Bendersky added the comment:

Thanks Ethan :)

>From my point of view this is LGTM, as long as:

* There's ReST documentation
* You remove the code to support extensions and customizations not mandated by 
PEP 435. As I mentioned before, this seems to be a YAGNI that complicates the 
code needlessly. It's find to keep the changes in some external repo and at a 
later point discuss their gradual addition similarly to the way Nick has been 
pushing enhancements through additional issues.

We can always add more capabilities to Enum. We can "never" take them away once 
added, and this complicated code will remain with us forever even if no one 
ends up using it.

--

___
Python tracker 

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

[issue877121] configure detects incorrect compiler optimization

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

The 3.2 change r85656 removes OPT:Olimit, IMO this should not be backported.

But 2.7 already has this warning fixed for icc:
http://hg.python.org/cpython/rev/e7c96c1d144b/
We should do the same here. What's the correct way to detect Oracle Studio 
compiler?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue9951] introduce bytes.hex method

[Terry J. Reedy]

Terry J. Reedy added the comment:

Also #3532

--
nosy: +terry.reedy
versions: +Python 3.4 -Python 3.3

___
Python tracker 

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

[issue923697] SAX2 'property_encoding' feature not supported

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Mark, the "http://www.python.org/sax/properties/encoding"; is not meant to be a 
web page. It's like an attribute name, but fully qualified so that attributes 
given by different organizations don't clash.
(There may be different usages of "encoding": is it the one set by the user, or 
the one determined by the parser? according to Python docs, here it's both)

Python's default Expat parser doesn't support this feature, so the present 
behavior is correct.
Proper support should not be difficult to add, with a XmlDeclHandler.

--
nosy: +amaury.forgeotdarc
stage: test needed -> needs patch

___
Python tracker 

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

[issue592703] HTTPS does not handle pipelined requests

[Antoine Pitrou]

Antoine Pitrou added the comment:

The original report is so under-specified that it's pointless to keep it open. 
If you encounter an actual bug, feel free to open another issue :)

--
nosy: +pitrou
status: pending -> closed

___
Python tracker 

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

[issue18056] Document importlib._bootstrap.NamespaceLoader

[Eric V. Smith]

Eric V. Smith added the comment:

No reason I can think of, other than it never occurred to me to do it.

--

___
Python tracker 

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

[issue18058] Define is_package for NamespaceLoader

[Eric V. Smith]

Eric V. Smith added the comment:

I think it's just an oversight.

--
assignee: barry -> brett.cannon

___
Python tracker 

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

[issue592703] HTTPS does not handle pipelined requests

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
status: open -> pending

___
Python tracker 

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

[issue592703] HTTPS does not handle pipelined requests

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
resolution:  -> works for me
status: pending -> open

___
Python tracker 

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

[issue592703] HTTPS does not handle pipelined requests

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Tried with python2.7.3
I used http://code.activestate.com/recipes/576673-python-http-pipelining/ just 
replacing the initial call to HTTPConnection() by HTTPSConnection().

The example succeeeds, fetches the three pages, and I checked with strace that 
the same connection is used for all requests (only reads and writes of 
encrypted content, no close or connect in between). 

Is this enough for closing this issue? Or is there a different way to pipelines 
requests that we should support?

--
nosy: +amaury.forgeotdarc
status: open -> pending
versions: +3rd party -Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue18069] Subprocess picks the wrong executable on Windows

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
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

[issue18069] Subprocess picks the wrong executable on Windows

[berdario]

New submission from berdario:

To reproduce:
I installed 2 versions of python: python2.7 and python3.3, both in C:\
I then used the distribute-setup and get-pip script on both interpreters
http://python-distribute.org/distribute_setup.py
https://raw.github.com/pypa/pip/master/contrib/get-pip.py

I copied C:\Python33\Scripts\pip.exe to C:\Python33\pip.exe

And I set up the PATH system variable, to have 
C:\Python27\Scripts;C:\Python33\; at the beginning

When invoking python, it'll pick Python3.3, as expected, and then:

> python
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from shutil import which
>>> import os
>>> os.environ['PATH']
'C:\\Python27\\Scripts;C:\\Python33\\;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program
 Files\\Microsoft Windows Performance Toolkit\\;C:\\Program Files 
(x86)\\Bazaar;C:\\Program Files\\Mercurial\\;C:\\MinGW\\bin; C:\\Program Files 
(x86)\\Git\\cmd;C:\\Users\\Dario\\Documents\\WindowsPowerShell\\Modules\\Pscx\\Apps;C:\\Users\\Dario\\Applications\\bin;C:\\Users\\Dario\\Applications\\emacs\\bin'
>>> which('pip')
'c:\\python27\\scripts\\pip.exe'
>>> from subprocess import call
>>> call('pip --version'.split())
Cannot open C:\Python33\pip-script.py
2
>>>

--
components: Interpreter Core, Windows
messages: 190106
nosy: berdario
priority: normal
severity: normal
status: open
title: Subprocess picks the wrong executable on Windows
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

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

[issue18068] pickle + weakref.proxy(self)

[Oleg Broytman]

New submission from Oleg Broytman:

Hello! I've found a problematic behaviour of pickle when it pickles
(direct or indirect) weak proxies to self. I suspect pickle cannot
detect reference loops with weak proxies. I managed to narrow the case
to the following example:

import pickle, weakref

class TestPickle(object):
def __init__(self):
self.recursive = weakref.proxy(self)

def __getstate__(self):
print "__getstate__", id(self)
return self.__dict__.copy()

def __setstate__(self, d):
print "__setstate__", id(self)
self.__dict__.update(d)

print "- 1 -"
test = TestPickle()
print "- 2 -"
data = pickle.dumps(test, pickle.HIGHEST_PROTOCOL)
print "- 3 -"
test2 = pickle.loads(data)
print "- 4 -"
print "Result:", id(test2)
print "- 5 -"

   It prints:

- 1 -
- 2 -
__getstate__ 3075348620
__getstate__ 3075348620
- 3 -
__setstate__ 3075348844
__setstate__ 3075349004
- 4 -
Result: 3075349004
- 5 -

   That is, __getstate__ is called twice for the same object. And what
is worse, __setstate__ is called twice for different objects. The
resulting unpickled object is the last one, but in the library that I
have been debugging creation of two different objects during unpickling
is a bug.

   I can fix it by avoiding pickling the proxy and recreating the proxy
on unpickling:

import pickle, weakref

class TestPickle(object):
def __init__(self):
self.recursive = weakref.proxy(self)

def __getstate__(self):
print "__getstate__", id(self)
d = self.__dict__.copy()
del d['recursive']
return d

def __setstate__(self, d):
print "__setstate__", id(self)
self.__dict__.update(d)
self.recursive = weakref.proxy(self)

print "- 1 -"
test = TestPickle()
print "- 2 -"
data = pickle.dumps(test, pickle.HIGHEST_PROTOCOL)
print "- 3 -"
test2 = pickle.loads(data)
print "- 4 -"
print "Result:", id(test2)
print "- 5 -"

- 1 -
- 2 -
__getstate__ 3075070092
- 3 -
__setstate__ 3075070188
- 4 -
Result: 3075070188
- 5 -

   But I wonder if it's a bug that should be fixed? If it's an expected
behaviour it perhaps should be documented as a warning in docs for
pickle or weakref or both.

--
components: Library (Lib)
messages: 190105
nosy: phd
priority: normal
severity: normal
status: open
title: pickle + weakref.proxy(self)
type: behavior
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue18067] In considering the current directory for importing modules, Python does not honour the output of os.getcwd()

[R. David Murray]

R. David Murray added the comment:

This is a duplicate of issue 6386, which does contain an explanation of the 
behavior.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> importing yields unexpected results when initial script is a 
symbolic link
type:  -> behavior

___
Python tracker 

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

[issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

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

[issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function "inspect.getargspec()"

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

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

[issue18062] m68k FPU precision issue

[mirabilos]

mirabilos added the comment:

Eero Tamminen dixit:

>> > Now as additional data point, UAE/WinUAE/etc. would be interesting.
>
>I built the test with fpu_control.h header from eglibc, using
>Sparemint GCC 2.9.5 (with 2010 binutils) and MiNTlib.  When it's

Nice ;)

>I.e. it seems that WinUAE FPU emulation is also lacking FPUCW change
>handling (for precision).
>
>(Hatari's WinUAE CPU core code was synched with upstream last year.)

OK, thanks. I’d just say let’s say changing FPU precision is not
part of the target we support. (Funnily enough, ColdFire according
to the ’net has (unchangeable) 64-bit precision… maybe let’s just
say precision on m68k in general is not defined.)

bye,
//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt

--

___
Python tracker 

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

[issue7951] Should str.format allow negative indexes when used for __getitem__ access?

[Mark Lawrence]

Mark Lawrence added the comment:

Todd's patch strikes me as fine.  If something more detailed is needed I think 
it would be better to raise a separate issue.

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue7940] re.finditer and re.findall should support negative end positions

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I'm worrying about backward compatibility. See also issue7951.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue1693050] \w not helpful for non-Roman scripts

[Matthew Barnett]

Matthew Barnett added the comment:

I had to check what re does in Python 3.3:

>>> print(len(re.match(r'\w+', 'हिन्दी').group()))
1

Regex does this:

>>> print(len(regex.match(r'\w+', 'हिन्दी').group()))
6

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Ethan Furman]

Ethan Furman added the comment:

Wow.  I definitely felt like an apprentice after reading the changes.  Thanks, 
Eli, that looks worlds better!

--

___
Python tracker 

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

[issue18067] In considering the current directory for importing modules, Python does not honour the output of os.getcwd()

[Shriramana Sharma]

New submission from Shriramana Sharma:

Hello. I first asked about this at 
https://groups.google.com/d/topic/comp.lang.python/ZOGwXGU_TV0/discussion and 
am only posting this issue due to no reply there.

I am using Python 2.7.4 and Python 3.3.1 (default packages) on Kubuntu Raring. 
On both I experience this same bug.

This bug has to do with a Python script called via a symlink. To illustrate it 
I have included a minimal test case tarball as an attachment. Just run sh 
test.sh at root of the extracted tree to see what's happening.

I am quite unpleasantly surprised that when one calls a Python script via a 
symlink, and that script asks for a module to be imported, Python searches the 
directory in which the *target* of the link exists, and uses the version of the 
library present *there* if any, and raises an exception if not. It even follows 
a chain of symlinks. Any version of the library present in the same directory 
as the (user-called) symlink is ignored. This is totally counter-intuitive 
behaviour and should be treated as a bug and fixed.

This is all the more frustrating since running print(os.getcwd()) from the same 
script correctly prints the current directory in which the *symlink* and not 
its target exists. (See output of the attached scripts.)

Now the symlink is only a user-level file system convenience indicating that I 
create a virtual file in one place pointing to another file elsewhere. Whatever 
the rest of the contents of the directory containing the other file is 
immaterial to me -- I am only interested in the one file I am symlinking to. 

I am executing a script from a given directory. os.getcwd() correctly prints 
the path of that directory. I also have a library in that same directory for 
the script to import. I would expect Python to honour the output of os.getcwd() 
in doing import too.

I read through http://docs.python.org/3/reference/import.html and didn't seem 
to find any explanation for the current illogical behaviour. (Please point out 
if I have missed it.)

(Note that the same behaviour does not happen with hardlinks, probably since 
the filesystem itself shows the whole file as existing at the current location.)

Output of the test.sh script:

 Trying english/run.py 
CWD: /tmp/symlink-bug/english
Hello Shriramana!
 Trying english/run-link.py symlinked to ./run.py 
CWD: /tmp/symlink-bug/english
Traceback (most recent call last):
  File "run-link.py", line 3, in 
from greet import greet
ImportError: No module named greet
 Trying english/run-link-link.py symlinked to ./run-link.py symlinked to 
english/run.py 
CWD: /tmp/symlink-bug/english
Hello Shriramana!
 Trying sanskrit/run-slink.py symlinked to english/run.py 
CWD: /tmp/symlink-bug/sanskrit
Hello Shriramana!
 Trying sanskrit/run-hlink.py hardlinked to english/run.py 
CWD: /tmp/symlink-bug/sanskrit
Namaste Shriramana!

Expected output: (see esp items marked 1 and 2 below):

 Trying english/run.py 
CWD: /tmp/symlink-bug/english
Hello Shriramana!
1  Trying english/run-link.py symlinked to ./run.py 
CWD: /tmp/symlink-bug/english
Hello Shriramana!
 Trying english/run-link-link.py symlinked to ./run-link.py symlinked to 
english/run.py 
CWD: /tmp/symlink-bug/english
Hello Shriramana!
2  Trying sanskrit/run-slink.py symlinked to english/run.py 
CWD: /tmp/symlink-bug/sanskrit
Namaste Shriramana!
 Trying sanskrit/run-hlink.py hardlinked to english/run.py 
CWD: /tmp/symlink-bug/sanskrit
Namaste Shriramana!

--
components: Extension Modules
files: symlink-bug.tar.gz
messages: 190098
nosy: jamadagni
priority: normal
severity: normal
status: open
title: In considering the current directory for importing modules, Python does 
not honour the output of os.getcwd()
Added file: http://bugs.python.org/file30386/symlink-bug.tar.gz

___
Python tracker 

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

[issue5124] IDLE - pasting text doesn't delete selection

[Roger Serwy]

Roger Serwy added the comment:

There are many X11 applications that replace the selection with pasted text. 
GTK and Qt widgets behave that way. Here's a brief list: gedit (GTK), gummi 
(GTK), kate (Qt), texmaker (Qt).

Tkinter, for me, has become increasingly frustrating due to these subtle 
platform differences. (See #14146, #13582, and many more that deal with Tk on 
Mac.) For IDLE, I consider these behavior differences bugs.

The attached patch "fixes" this issue.

--
keywords: +patch
Added file: http://bugs.python.org/file30385/issue5124.patch

___
Python tracker 

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

[issue8191] Make arg0 required argument in os.execl* functions

[R. David Murray]

R. David Murray added the comment:

Mark, just asking that question doesn't really move the issue forward.  Doing 
some research to see if there was any discussion on python-dev, and if not 
summarizing the issues and starting one, would be what could move the issue 
forward.

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Eli Bendersky]

Eli Bendersky added the comment:

I tweaked the code a bit (no functionality changes, mostly cleanups and a bit 
of refactoring). Figured it will be easier to just send an updated patch than 
another review. The diff from patch 06 can be seen via the Rietveld interface.

Also, after reading the code more carefully, I think we're doing a mistake by 
over-complicating it for the sake of custom enum metaclasses and 
over-customization (like auto numbering). The original point Guido raised 
against auto-numbering was too much magic in the implementation. Well, we 
already have that in Lib/enum.py - the code is so complex it seems fragile 
because of the tight coupling with many class and metaclass related protocols. 
Just defining a wholly new enum implementation that does something very 
specific seems simpler than customizing the existing one.

I'd suggest we stick to the existing Enum + IntEnum, giving up the more complex 
customizations for now. It can always be added in the future if we see it's 
very important.

--
Added file: http://bugs.python.org/file30384/pep-0435.07.eliben.patch

___
Python tracker 

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

[issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C

[Jean Brouwers]

Jean Brouwers added the comment:

I haven't retested that yet, but I will as soon as can.

/Jean Bouwers

On May 26, 2013, at 7:57 AM, Mark Lawrence  wrote:

> 
> Mark Lawrence added the comment:
> 
> is this still a problem with 2.7 or 3.x?
> 
> --
> nosy: +BreamoreBoy
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue17700] Update Curses HOWTO for 3.4

[A.M. Kuchling]

A.M. Kuchling added the comment:

I can't make sense of unget_wch.  I used this test program:



import curses

def main(stdscr):
stdscr.addstr(0,0, "Key")
stdscr.refresh()
curses.ungetch(0x0149)
while True:
ch = stdscr.get_wch()
stdscr.addstr(1,1, repr(ch) + '  ')
if ch == 'q':
break

curses.wrapper(main)



If I use curses.unget_wch(chr(0x0149)), the following get_wch() call returns 
-119, not 0x149.

The whole area of wide character support in curses is just a mystery, and I 
don't know how to resolve my questions.  I'll close this item, since I have 
nothing further to add to the curses howto.

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

[issue13772] listdir() doesn't work with non-trivial symlinks

[Jason R. Coombs]

Jason R. Coombs added the comment:

Since there's been no additional criticism or discussion on this matter, I'll 
plan to commit the proposed patch to restore target directory detection. Since 
the functionality was removed in a bugfix release, it should be acceptable to 
restore it in a bugfix release. I know 3.2 no longer gets non-security 
releases, so I'll port the patch to 3.3 and apply it to 3.3 and default.

I'll plan to do this tomorrow unless there's further discussion.

--

___
Python tracker 

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

[issue18062] m68k FPU precision issue

[mirabilos]

mirabilos added the comment:

Laurent Vivier dixit:

> For the "etc" ;-) , in Qemu, I have:

Hm, I thought qemu did not emulate an MMU?

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

--

___
Python tracker 

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

[issue18061] m68k Python 3.3 test results

[mirabilos]

mirabilos added the comment:

Serhiy Storchaka dixit:

>> >Do you run tests as root?
>> Yes.
>
>Well, this is issue17746.

OK, I’ll re-run the tests as regular user (need to create one… ☺)
and with all those fixes applied, then we’ll have a look again.

(This will take a while.)

Thanks,
//mirabilos
-- 
 Oh, ich hab mim Bauch Mittelklick gemacht, als ich nach dem
Kaffee gegriffen habe…
 Cool, ich hab ne neue eMail-Signatur
 Sag doch sowas nich, wenn ich den Kaffee in der Hand habe!
Gib mir nen Lappen! Schnell! Das kommt aber nicht mit in die Signatur!

--

___
Python tracker 

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

[issue17314] Stop using imp.find_module() in multiprocessing

[Brett Cannon]

Brett Cannon added the comment:

In the common case of SourceLoader it will set __loader__, __package__, 
__file__, and __cached__.

--

___
Python tracker 

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

[issue18066] Remove SGI-specific code from pty.py

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
components: +Library (Lib)
versions: +Python 3.4

___
Python tracker 

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

[issue18032] set methods should specify whether they consume iterators "lazily"

[Ezio Melotti]

Changes by Ezio Melotti :


--
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.3, Python 3.4 -Python 3.2

___
Python tracker 

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

[issue18033] Example for Profile Module shows incorrect method

[Ezio Melotti]

Changes by Ezio Melotti :


--
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

___
Python tracker 

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

[issue18042] Provide enum.unique class decorator

[Ezio Melotti]

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

[issue18043] No mention of `match.regs` in `re` documentation

[Ezio Melotti]

Changes by Ezio Melotti :


--
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett

___
Python tracker 

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

[issue18044] Email headers do not properly decode to unicode.

[Ezio Melotti]

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

[issue18047] Descriptors get invoked in old-style objects and classes

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage:  -> needs patch

___
Python tracker 

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

[issue18036] "How do I create a .pyc file?" FAQ entry is out of date

[Ezio Melotti]

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

[issue18034] Last two entries in the programming FAQ are out of date (import related)

[Ezio Melotti]

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

[issue766910] fix one or two bugs in trace.py

[Eli Bendersky]

Eli Bendersky added the comment:

Ah, no time, no time... :-/

I may get back to this in the future. Bumping to more relevant versions for now.

--
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2

___
Python tracker 

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

[issue18062] m68k FPU precision issue

[mirabilos]

mirabilos added the comment:

Laurent Vivier dixit:

> BTW, the result on a real CPU (68040) is :

68881 even ;-)

> test#1 fail: 1.0E+00
> test#2 fail: 1.00040E+16
> changing FPU control word from  to 0080 => 0080
> test#1 good: 1.00022E+00
> test#2 good: 1.00020E+16

Thanks, that’s what I was guessing. I get similar results on i386.

Now as additional data point, UAE/WinUAE/etc. would be interesting.

Even so, I’d be very reluctant to add this code to Python to make
it change the FPU mode, because Python is heavily used in Debian,
and getting varying results between emulation and bare metal is
something we’d like to not have…

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

--

___
Python tracker 

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

[issue18062] m68k FPU precision issue

[mirabilos]

mirabilos added the comment:

Mark Dickinson dixit:

>If there are tests failing with the 'legacy' mode, that may just
>indicate buggy tests that haven't been properly marked as depending on
>the short float repr. (E.g., by decorating with

I think that’s what we’re seeing here.

Python 3.3.1 (default, May 10 2013, 02:52:57)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.float_repr_style
'legacy'

Andreas Schwab dixit:

>What is the exact sequence of fpu insns?

That’s all gcc-generated code and a system header…

In main (after commenting out the second getcw and printf):

jsr runtests
#APP
| 34 "x.c" 1
fmove.l %fpcr, %d2
| 0 "" 2
#NO_APP
move.l %d2,-4(%fp)
move.l #128,-8(%fp)
#APP
| 40 "x.c" 1
fmove.l -8(%fp), %fpcr
| 0 "" 2
#NO_APP
jsr runtests

And the subroutine:

runtests:
link.w %fp,#-24
move.l %d3,-(%sp)
move.l %d2,-(%sp)
move.l #1072693247,-8(%fp)
move.l #-1,-4(%fp)
move.l -8(%fp),%d0
move.l -4(%fp),%d1
fmovecr #0x32,%fp0
move.l %d1,-(%sp)
move.l %d0,-(%sp)
fmove.d (%sp)+,%fp1
fdiv.x %fp1,%fp0
fmove.d %fp0,-(%sp)
move.l (%sp)+,%d0
move.l (%sp)+,%d1
move.l %d0,-16(%fp)
move.l %d1,-12(%fp)
move.l -16(%fp),%d2
move.l -12(%fp),%d3
move.l -16(%fp),%a0
move.l -12(%fp),%a1
move.l #1072693248,%d0
clr.l %d1
move.l %a1,-(%sp)
move.l %a0,-(%sp)
fmove.d (%sp)+,%fp0
move.l %d1,-(%sp)
move.l %d0,-(%sp)
fmove.d (%sp)+,%fp1
fcmp.x %fp1,%fp0
fjne .L2
move.l #.LC0,%d0
jra .L3
.L2:
move.l #.LC1,%d0
.L3:
move.l #.LC2,%d1
move.l %d3,-(%sp)
move.l %d2,-(%sp)
move.l %d0,-(%sp)
move.l %d1,-(%sp)
jsr printf
lea (16,%sp),%sp
move.l #1128383353,-8(%fp)
move.l #937459712,-4(%fp)
move.l #1074266106,-16(%fp)
move.l #-1043161657,-12(%fp)
move.l -8(%fp),%a0
move.l -4(%fp),%a1
move.l -16(%fp),%d0
move.l -12(%fp),%d1
move.l %a1,-(%sp)
move.l %a0,-(%sp)
fmove.d (%sp)+,%fp0
move.l %d1,-(%sp)
move.l %d0,-(%sp)
fmove.d (%sp)+,%fp1
fadd.x %fp1,%fp0
fmove.d %fp0,-(%sp)
move.l (%sp)+,%d0
move.l (%sp)+,%d1
move.l %d0,-24(%fp)
move.l %d1,-20(%fp)
move.l -24(%fp),%a0
move.l -20(%fp),%a1
move.l -24(%fp),%d0
move.l -20(%fp),%d1
move.l %d1,-(%sp)
move.l %d0,-(%sp)
fmove.d (%sp)+,%fp0
fcmp.d #0x4341c37937e08002,%fp0
fjne .L4
move.l #.LC0,%d0
jra .L5
.L4:
move.l #.LC1,%d0
.L5:
move.l #.LC3,%d1
move.l %a1,-(%sp)
move.l %a0,-(%sp)
move.l %d0,-(%sp)
move.l %d1,-(%sp)
jsr printf
lea (16,%sp),%sp
move.l -32(%fp),%d2
move.l -28(%fp),%d3
unlk %fp
rts

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec

--

___
Python tracker 

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

[issue6483] Modules are not deallocated correctly if m_size = -1

[Mark Lawrence]

Mark Lawrence added the comment:

Please correct me if I'm wrong but I believe this applies to all Python 3 
versions.

--
nosy: +BreamoreBoy
versions: +Python 3.3, Python 3.4

___
Python tracker 

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

[issue8508] 2to3 fixer for gettext's .ugettext

[Mark Lawrence]

Mark Lawrence added the comment:

Barry, would you like to follow up on this?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue18066] Remove SGI-specific code from pty.py

[A.M. Kuchling]

New submission from A.M. Kuchling:

pty.py contains some code that tries to do 'import sgi' and then does something 
SGI-specific.  sgimodule.c was dropped in 3.0alpha1, so this code is now 
useless.

The attached patch removes it; I'm posting the code review largely in case 
someone wants to suggest changes to the docstring.

--
files: remove-sgi.txt
messages: 190083
nosy: akuchling
priority: normal
severity: normal
stage: patch review
status: open
title: Remove SGI-specific code from pty.py
type: resource usage
Added file: http://bugs.python.org/file30383/remove-sgi.txt

___
Python tracker 

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

[issue967161] pty.spawn() enhancements

[A.M. Kuchling]

A.M. Kuchling added the comment:

It looks like the problem on OpenIndiana with #2489 was fixed. As of May 25th, 
the 3.x build on OpenIndiana is a green. 
http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/5962

So, 2) is a misunderstanding and 1) was carried out in #2489 (despite any 
objections to putting a feature enhancement in a bugfix, the feature is still 
there in trunk).  Therefore, I'm going to close this bug because there's 
nothing to do.

--
resolution:  -> out of date
stage: test needed -> 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

[issue18062] m68k FPU precision issue

[Andreas Schwab]

Andreas Schwab added the comment:

Thorsten Glaser  writes:

> root@ara3:~ # ./a.out
> test#1 fail: 1.0E+00
> test#2 fail: 1.00040E+16
> changing FPU control word from  to 0080 => 0080
> test#1 fail: 1.0E+00
> test#2 fail: 1.00040E+16

What is the exact sequence of fpu insns?

Andreas.

--
nosy: +schwab

___
Python tracker 

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

[issue8191] Make arg0 required argument in os.execl* functions

[Mark Lawrence]

Mark Lawrence added the comment:

What conclusions were drawn on python-dev about this issue?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue749722] isinstance and weakref proxies.

[Antoine Pitrou]

Antoine Pitrou added the comment:

Mark, this kind of message isn't useful.
The general problem here is not whether it is interesting or not, it is whether 
it is desireable. My own take is that it would threaten to break existing code, 
and that making the proxy *too* transparent would be detrimental to 
debuggability. But people may disagree, and this can only be solved by a 
discussion on e.g. python-dev.

--
nosy: +pitrou

___
Python tracker 

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

[issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C

[Mark Lawrence]

Mark Lawrence added the comment:

is this still a problem with 2.7 or 3.x?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue8083] urllib proxy interface is too limited

[Tshepang Lekhonkhobe]

Changes by Tshepang Lekhonkhobe :


--
nosy: +tshepang
versions: +Python 3.4 -Python 2.7, Python 3.2

___
Python tracker 

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

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[koobs]

koobs added the comment:

I'm happy to move them back upon request, or create a FreeBSD/ZFS buildslave 
specially for the job, just let me know.

--

___
Python tracker 

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

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[koobs]

koobs added the comment:

I've moved both of the FreeBSD buildbot slaves off their ZFS-backed home 
directories and back to good old UFS.

I want to ensure FreeBSD support continues to improve, and having slaves get 
noticed when they fail or regress with ongoing development is a big part of 
that.

This is hard to achieve without movement on this issue, either in the form of a 
conditional skip, workaround or ultimate resolution

--

___
Python tracker 

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

[issue1693050] \w not helpful for non-Roman scripts

[Mark Lawrence]

Mark Lawrence added the comment:

Am I correct in saying that this must stay open as it targets the re module but 
as given in msg81221 is fixed in the new regex module?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue8238] Proxy handling

[Mark Lawrence]

Mark Lawrence added the comment:

I can't even try to reproduce this as I've no corporate network as a test bed.  
Is this still an issue with Python 2.7 or the reworked urllib in Python 3.x?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function "inspect.getargspec()"

[Mark Lawrence]

Mark Lawrence added the comment:

Tormen could you provide a patch for this?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue18040] SIGINT catching regression on windows in 2.7

[Tim Golden]

Tim Golden added the comment:

Correction: I see the desired behaviour in 3.3/3.4 which is where the
overhaul to Ctrl-C handling on Windows was applied. I still can't see it
in 2.6 or in 3.1/3.2 on Windows.

The problem lies in the fact that PyOS_InterruptOccurred and 
PyErr_CheckSignals from signalmodule.c both check and reset signalled 
events. The former is used (solely within myreadline.c) to determine 
whether a SIGINT has fired; the latter is called in many different 
places to initiate Python's signal-handling but doesn't return any 
information about which signal fired.

The check in line 70 of Parser/myreadline.c determines that a SIGINT 
signal has fired, but clears that signal at the same time. Any later 
call to PyErr_CheckSignals will not see that the SIGINT had fired.

The 3.3+ situation is different, as a Windows event is the indication 
that SIGINT was raised, and the check for this doesn't affect the 
internal Handlers table which is examined by PyErr_CheckSignals.

The attached patch to signalmodule.c appears to produce SIGINT signal 
handling as desired. Tested only on Windows. It's not clear whether any 
unittest could be produced for this kind of functionality.

--
keywords: +patch
Added file: http://bugs.python.org/file30382/signalmodule.patch

___
Python tracker 

___diff --git a/Modules/signalmodule.c b/Modules/signalmodule.c
--- a/Modules/signalmodule.c
+++ b/Modules/signalmodule.c
@@ -974,7 +974,6 @@
 if (PyThread_get_thread_ident() != main_thread)
 return 0;
 #endif
-Handlers[SIGINT].tripped = 0;
 return 1;
 }
 return 0;
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16580] Add examples to int.to_bytes and int.from_bytes

[Mark Dickinson]

Mark Dickinson added the comment:

The `from_bytes` example code looks fine to me, except that I'd probably use 
`enumerate` in the iteration;  i.e.,

sum(b << 8*i for i, b in enumerate(little_ordered))

instead of

sum(little_ordered[i] << i*8 for i in range(len(little_ordered)))

Also, in:

   if signed and little_ordered and (little_ordered[-1] & 0x80):

I wondered why you needed the `little_ordered` check.  But I see that 
`int.from_bytes(b'', 'little', signed=True)` produces `0`, which is a little 
bit disappointing:  I was expecting an exception.  (A signed format should have 
a sign bit, which is impossible if the length of the byte string is 0.)

The `to_bytes` example code is missing range checks for the input.  It may be 
clearer to simply state that in the docs, instead of modifying the example code 
to add the range checks.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue18059] Add multibyte encoding support to pyexpat

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: 
http://bugs.python.org/file30380/pyexpat_multibyte_encodings_3.patch

___
Python tracker 

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

[issue18059] Add multibyte encoding support to pyexpat

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Patch updated. Yet some tests added and yet some bugs fixed.

--
Added file: http://bugs.python.org/file30381/pyexpat_multibyte_encodings_4.patch

___
Python tracker 

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

[issue18062] m68k FPU precision issue

[Mark Dickinson]

Mark Dickinson added the comment:

It's also an option not to use dtoa.c:  Python still has fallback code that 
uses the OS double <-> char* conversions for the case where the configuration 
step can't figure out how to change the FPU control word.  In that case 
compilation should still succeed, and the resulting Python would show:

>>> import sys
>>> sys.float_repr_style
'legacy'

If there are tests failing with the 'legacy' mode, that may just indicate buggy 
tests that haven't been properly marked as depending on the short float repr.  
(E.g., by decorating with "@unittest.skipUnless(getattr(sys, 
'float_repr_style', '') == 'short'"), or poorly-designed tests that could be 
rewritten.

--

___
Python tracker 

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

[issue18062] m68k FPU precision issue

[Mark Dickinson]

Mark Dickinson added the comment:

> The problem with changing the FPUCW on i387 is that it changes
> from 64/15 bit mantissa/exponent to 53/15 bit which is still
> not the 53/11 bit of IEEE double, so you *still* get double-
> rounding issues (with denormal numbers only, I guess) because
> the internal precision is still higher.

That's not a problem for dtoa.c, at least: dtoa.c avoids any use of subnormals 
in intermediate calculations.  It's not really too much of a problem for Python 
in general, either.  Windows typically operates in this mode.

--

___
Python tracker 

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

[issue17746] test_shutil.TestWhich.test_non_matching_mode fails when running as root

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue18059] Add multibyte encoding support to pyexpat

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file30380/pyexpat_multibyte_encodings_3.patch

___
Python tracker 

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

[issue18059] Add multibyte encoding support to pyexpat

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: 
http://bugs.python.org/file30378/pyexpat_multibyte_encodings_2.patch

___
Python tracker 

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