[issue3672] Ill-formed surrogates not treated as errors during encoding/decoding

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2009-04-29 22:39, Martin v. Löwis @psf.upfronthosting.co.za wrote:
> Martin v. Löwis  added the comment:
> 
> I think we could preserve the marshal format with yet another error
> handler - one that emits half surrogates into their intuitive form.

That's a good idea. We could have an error handler which then let's
the codec accept lone surrogates for utf-8 or just add a new codec
which does this and use that for marshal.

Still, this can only go into 3.1.

--

___
Python tracker 

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

[issue5885] uuid.uuid1() is too slow

[Wang Chun]

New submission from Wang Chun :

uuid.uuid1() currently uses two different ways to generate a uuid. If 
the system call "uuid_generate_time" is available, uuid1() uses the 
system call via the ctypes interface, otherwise, it uses pure Python 
code to generate a uuid. The problem is, the C interface 
"uuid_generate_time" is even slower than the Python code. The ctypes 
interface is too slow. According to my test, it took 55 microseconds to 
generate a uuid via ctypes interface but only 45 microseconds via the 
Python code. I also tried to test the performance of the 
"uuid_generate_time" C API itself. It takes C code 12 microseconds. Most 
of the time were wasted on ctypes. I believe we need to drop ctypes and 
write a Python extensions in C for this job.

--
components: Library (Lib)
messages: 86840
nosy: wangchun
severity: normal
status: open
title: uuid.uuid1() is too slow
type: performance
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

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

[issue5885] uuid.uuid1() is too slow

[Wang Chun]

Wang Chun  added the comment:

This is my test on another faster machine.

$ cat test.py
import sys, time, uuid
N = int(sys.argv[1])
t = time.time()
for x in xrange(N):
uuid.uuid1()
print('%.3f microseconds' % ((time.time() - t) * 100.0 / N))
$ cat test.c
#include 
#include 
#include 

int main(int argc, char *argv[])
{
int i, n;
double t1, t2;
uuid_t uuid;
struct timeval t;
struct timezone tz;
sscanf(argv[1], "%d", &n);
gettimeofday(&t, &tz);
t1 = (double)t.tv_sec + (double)t.tv_usec / 100.0;
for (i = 0; i < n; i++) {
uuid_generate_time(uuid);
}
gettimeofday(&t, &tz);
t2 = (double)t.tv_sec + (double)t.tv_usec / 100.0;
printf("%.3f microseconds\n", (t2 - t1) * 100.0 / n);
return 0;
}
$ gcc -l uuid -o test test.c
$ python test.py 5
25.944 microseconds
$ python test.py 20
25.810 microseconds
$ python test.py 100
25.865 microseconds
$ ./test 5
0.214 microseconds
$ ./test 20
0.214 microseconds
$ ./test 100
0.212 microseconds
$

--

___
Python tracker 

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

[issue957650] Fix for bugs relating to ntpath.expanduser()

[Geoffrey Bache]

Geoffrey Bache  added the comment:

Just ran into this myself, and would agree with Christian's comments. On
my system, my home directory is a mounted network drive, hence "H:\". It
was a bit of a surprise when os.path.expanduser("~fred") returned
"H:\\fred"...

This seems broken to me. It's surely better to have reliable functions
that either work or return the path unchanged, than ones that guess and
are wrong some of the time. At least in the above case it should be
possible to add a special case.

Will this be considered for Python 2.7 now? I'd suggest opening a new
bug or reopening this one if so.

--
nosy: +gjb1002

___
Python tracker 

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

[issue957650] Fix for bugs relating to ntpath.expanduser()

[Geoffrey Bache]

Geoffrey Bache  added the comment:

In fact, wouldn't a very simple fix be to not return paths that don't
exist? That would probably catch 90% of the cases.

--

___
Python tracker 

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

[issue5883] detach() implementation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Reviewers: ,

Please review this at http://codereview.appspot.com/52075

Affected files:
   Doc/library/io.rst
   Lib/_pyio.py
   Lib/test/test_io.py
   Modules/_io/bufferedio.c
   Modules/_io/textio.c

--

___
Python tracker 

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

[issue5883] detach() implementation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

http://codereview.appspot.com/52075/diff/1/2
File Doc/library/io.rst (right):

http://codereview.appspot.com/52075/diff/1/2#newcode366
Line 366: Disconnect this buffer from its underlying raw stream and
return it.
This sentence is a bit ambiguous.
How about “Separate the underlying raw stream from the
:class:`BufferedIOBase` and return it” ?

Also, you should mention that some implementations will raise
io.UnsupportedOperation if the operation doesn't make sense.

http://codereview.appspot.com/52075/diff/1/2#newcode605
Line 605: in an unusable state.
You should mention that some implementations will raise
io.UnsupportedOperation if the operation doesn't make sense.

http://codereview.appspot.com/52075/diff/1/3
File Lib/_pyio.py (right):

http://codereview.appspot.com/52075/diff/1/3#newcode836
Line 836: return self
Uh, this doesn't really make sense. Better let it raise
io.UnsupportedOperation.

http://codereview.appspot.com/52075/diff/1/4
File Lib/test/test_io.py (right):

http://codereview.appspot.com/52075/diff/1/4#newcode532
Line 532: self.assertIs(buf.detach(), raw)
Perhaps a test of what happens when calling detach() a second time?
(it should probably raise a ValueError)

http://codereview.appspot.com/52075/diff/1/4#newcode1504
Line 1504: self.assertIs(t.detach(), b)
Same comment as for buffered binary tests.

http://codereview.appspot.com/52075/diff/1/5
File Modules/_io/bufferedio.c (right):

http://codereview.appspot.com/52075/diff/1/5#newcode470
Line 470: Py_CLEAR(self->raw);
Why not the simpler:
 raw = self->raw;
 self->raw = NULL;
?

http://codereview.appspot.com/52075/diff/1/5#newcode1547
Line 1547: self->detached = 1;
This should be 0.

http://codereview.appspot.com/52075/diff/1/6
File Modules/_io/textio.c (right):

http://codereview.appspot.com/52075/diff/1/6#newcode1080
Line 1080: "raw stream has been detached"); \
"underlying buffer" rather than "raw stream"?

http://codereview.appspot.com/52075/diff/1/6#newcode1092
Line 1092: "raw stream has been detached"); \
same as above

http://codereview.appspot.com/52075/diff/1/6#newcode1112
Line 1112: Py_CLEAR(self->buffer);
Why not the simpler:
 buffer = self->buffer;
 self->buffer = NULL;
?

http://codereview.appspot.com/52075

--

___
Python tracker 

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

[issue5886] curses/__init__.py: global name '_os' is not defined

[Andres Moreira]

New submission from Andres Moreira :

Hi, 
 using ipython2.5 in Ubuntu 9.04. I've get this traceback: 

In [1]: max?
---
NameError Traceback (most recent call last)

/var/lib/python-support/python2.5/IPython/iplib.py in
multiline_prefilter(self, line, continue_prompt)
   2272 out = []
   2273 for l in line.rstrip('\n').split('\n'):
-> 2274 out.append(self._prefilter(l, continue_prompt))
   2275 return '\n'.join(out)
   2276 

/var/lib/python-support/python2.5/IPython/iplib.py in _prefilter(self,
line, continue_prompt)
   2254 #print 'pre <%s> iFun <%s> rest <%s>' %
(pre,iFun,theRest)  # dbg
   2255 
-> 2256 return prefilter.prefilter(line_info, self)
   2257 
   2258 

/var/lib/python-support/python2.5/IPython/prefilter.py in
prefilter(line_info, ip)
149 handler = check(line_info, ip)
150 if handler:
--> 151 return handler(line_info)
152 
153 return ip.handle_normal(line_info)

/var/lib/python-support/python2.5/IPython/iplib.py in handle_help(self,
line_info)
   2443 if line:
   2444 #print 'line:<%r>' % line  # dbg
-> 2445 self.magic_pinfo(line)
   2446 else:
   2447 page(self.usage,screen_lines=self.rc.screen_length)

/var/lib/python-support/python2.5/IPython/Magic.py in magic_pinfo(self,
parameter_s, namespaces)
661 else:
662 self._inspect('pinfo', oname, detail_level=detail_level,
--> 663   namespaces=namespaces)
664 
665 def magic_pdef(self, parameter_s='', namespaces=None):

/var/lib/python-support/python2.5/IPython/Magic.py in _inspect(self,
meth, oname, namespaces, **kw)
746 pmethod(info.obj,oname,formatter)
747 elif meth == 'pinfo':
--> 748 pmethod(info.obj,oname,formatter,info,**kw)
749 else:
750 pmethod(info.obj,oname)

/var/lib/python-support/python2.5/IPython/OInspect.py in pinfo(self,
obj, oname, formatter, info, detail_level)
553 output = out.getvalue()
554 if output:
--> 555 page(output)
556 # end pinfo
557 

/var/lib/python-support/python2.5/IPython/genutils.pyc in page(strng,
start, screen_lines, pager_cmd)
   1663 # the checks.
   1664 term_flags = termios.tcgetattr(sys.stdout)
-> 1665 scr = curses.initscr()
   1666 screen_lines_real,screen_cols = scr.getmaxyx()
   1667 curses.endwin()

/usr/lib/python2.5/curses/__init__.py in initscr()
 28 # we call setupterm() here because it raises an error
 29 # instead of calling exit() in error cases.
---> 30 setupterm(term=_os.environ.get("TERM", "unknown"),
 31   fd=_sys.__stdout__.fileno())
 32 stdscr = _curses.initscr()

NameError: global name '_os' is not defined


I have python2.6 and python2.5 working together. I've attached a patch
to the code that make ipython2.5 working correctly.

--
components: Library (Lib)
files: curses_init_patch.patch
keywords: patch
messages: 86846
nosy: andrix
severity: normal
status: open
title: curses/__init__.py: global name '_os' is not defined
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file13822/curses_init_patch.patch

___
Python tracker 

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

[issue5886] curses/__init__.py: global name '_os' is not defined

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

These lines in curses/__init__.py have been added in trunk and patched 
in the python26-maint branch; never in python25-maint. 

How do they appear in your 2.5 version?
Do you use a customized version? In any case the patch was not correctly 
applied.
Closing as invalid. Please contact your package maintainer.

--
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue5887] mmap.write_byte out of bounds - no error, position gets screwed up

[Brian Mearns]

New submission from Brian Mearns :

Created an mmap for a file in update mode, seek to end of file, and
invoke write_byte. The file is not updated (as expected), but did not
get any error indicating the write was out of bounds, and when I invoke
tell(), it reports a position that is out of bounds. I check size(), and
it still reports the correct size (less than the value reported by
tell()). If I do seek(0, os.SEEK_END), it correctly returns to the end
of the map, instead of this bizarre no-mans land beyond the end.

This is on Windows XP.

Here's an example from the shell. (note that write() works as I would
expect, it raises an exception and doesn't modify the position):

>>> map.tell()
0
>>> map.size()
8
>>> map.seek(0, os.SEEK_END)
>>> map.tell()
8
>>> map.write("foo")
Traceback (most recent call last):
  File "", line 1, in 
ValueError: data out of range
>>> map.tell()
8
>>> map.size()
8
>>> map.write_byte('x')
>>> map.tell()
9
>>> map.size()
8
>>> print "WTF?"
WTF?
>>> map.write_byte('x')
>>> map.tell()
10
>>> map.size()
8
>>> map.flush()
1
>>> map.size()
8
>>> map.tell()
10
>>> map.seek(0, os.SEEK_END)
>>> map.tell()
8
>>> map.size()
8
>>>

--
messages: 86848
nosy: bmearns
severity: normal
status: open
title: mmap.write_byte out of bounds - no error, position gets screwed up
type: behavior
versions: Python 2.6

___
Python tracker 

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

[issue5888] mmap ehancement - resize with sequence notation

[Brian Mearns]

New submission from Brian Mearns :

I thought it would be nice if mmaps could generally look a little more
like sequences. Specifically, being able to resize+write using
square-bracket notation as with lists:

>>> x = [1,2,3,4,5]
>>> x
[1, 2, 3, 4, 5]
>>> x[2:2] = [6,7,8,9]
>>> x
[1, 2, 6, 7, 8, 9, 3, 4, 5]
>>>

If that could be done when x is an mmap.mmap, it'd be great.
alternatively, if mmap had an insert or an extend method that work like
with lists, the same behavior could be achieved without relying on mmap
specific method-names.

--
messages: 86849
nosy: bmearns
severity: normal
status: open
title: mmap ehancement - resize with sequence notation
type: feature request
versions: Python 2.6

___
Python tracker 

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

[issue5238] ssl makefile never closes socket

[Constantine Sapuntzakis]

Constantine Sapuntzakis  added the comment:

I ran into this problem when trying to use wrapsocket with httplib.py
and came up with the same fix.

The problem turns out to be even simpler than a ref counting issue.

In the current tree, the _fileobject constructor is called without the
close = True argument, As a result, _fileobject._close gets set to False
and _fileobject.close() method never propagates the close to
SSLSocket.close(). See line 269 of socket.py.

--
nosy: +csapuntz

___
Python tracker 

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

[issue5889] Extra comma in enum - fails on AIX

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

cc_r -qlanglvl=ansi -c  -DNDEBUG -O  -I. -IInclude -I./Include  
-DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c
"Objects/stringlib/string_format.h", line 37.15: 1506-275 (S) Unexpected
text ',' encountered.
make: *** [Objects/unicodeobject.o] Error 1


Not sure why the extra comma is required in the last enumeration.

--
components: Build
messages: 86851
nosy: srid, trentm
severity: normal
status: open
title: Extra comma in enum - fails on AIX
type: compile error
versions: Python 3.1

___
Python tracker 

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

[issue5889] Extra comma in enum - fails on AIX

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

typedef enum {
ANS_INIT,
ANS_AUTO,
ANS_MANUAL,  <--- Extra comma need to be removed
} AutoNumberState;   /* Keep track if we're auto-numbering fields */

--

___
Python tracker 

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

[issue5311] bdist_msi generates version number for pure Python packages

[Steven Bethard]

Steven Bethard  added the comment:

I'm still stuck on getting the right name to show up in ARP.

Another problem: it seems like we have to update the ProductCode at
runtime as well - otherwise, you can only have one module installed for
all the versions of Python you have on your machine. But if we generate
a new GUID at runtime, how do we make sure that the GUID for moduleXXX +
Python 2.6 is the same every time (as it should be for the MSI to
recognize when a product is being removed, reinstalled, etc.)

Thoughts? Is there a way to deterministically generate a GUID for each
Python version? (Note that it doesn't make sense to do this ahead of
time - an installer created for Python 3.1 should work with Python 3.2
as well.)

--

___
Python tracker 

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

[issue5311] bdist_msi generates version number for pure Python packages

[Steven Bethard]

Changes by Steven Bethard :


Removed file: http://bugs.python.org/file13649/bdist_msi.patch

___
Python tracker 

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

[issue5311] bdist_msi generates version number for pure Python packages

[Steven Bethard]

Steven Bethard  added the comment:

Updated the patch to make sure ProductName is set before ValidateProductID.

--
Added file: http://bugs.python.org/file13823/bdist_msi.patch

___
Python tracker 

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

[issue5311] bdist_msi generates version number for pure Python packages

[Martin v. Löwis]

Martin v. Löwis  added the comment:

> I'm still stuck on getting the right name to show up in ARP.

It may that indeed Installer blocks the property from being passed onto
the server side. Three things to try:
- inspect the log file, to see whether it is passed, and then whether it
  gets set. You do logging with "msiexec /i foo.msi /l*v foo.log".
- add the property to SecureCustomProperties, to have it passed to
  server mode; by default, only properties in UPPER_CASE get passed.
- alternatively, add an upper-case property, and make ProductName
  computed.

> Another problem: it seems like we have to update the ProductCode at
> runtime as well

I knew that would cause problems some day :-) I expected you to desire
this only for a single installation. Installing multiple copies is much
more difficult.

IIUC, a common approach is to use transforms, although I'm not sure how
precisely that would work.

A hacky approach might be to use computed uuids (if that can work at
all: I'm skeptical that you can change the productcode at runtime):
have a fixed ProductCode in the MSI, and then add the minor Python
version to the last digit of uuid. See Tools/msi/msi.py for how the
uuid of the Win64 installer changes from the one for the 32-bit
installer.

I think this is really is a question to ask on some MSI channels;
most likely, the answer is that this cannot possibly work.

--

___
Python tracker 

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

[issue1443504] locale.getpreferredencoding() dies when setlocale fails

[Jeroen Ruigrok van der Werven]

Jeroen Ruigrok van der Werven  added the comment:

Shouldn't the fallback be to setlocale(LC_CTYPE, "C") instead of
silently passing, though?

--
nosy: +asmodai

___
Python tracker 

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

[issue1443504] locale.getpreferredencoding() dies when setlocale fails

[Jeroen Ruigrok van der Werven]

Jeroen Ruigrok van der Werven  added the comment:

You don't want to completely nix the setlocale(LC_CTYPE, "") call
though. The "" denotes to grab the native environment, in other words,
to grab whatever the current user's LC_CTYPE environment variable is set
to (see `locale -a`) and then set the program's LC_CTYPE to that.

Of course, this might be set to something that might be valid (e.g.
cy_GB.ISO8859-15), but has no matching entry in /usr/share/locale (or
wherever your system provides it) and as such it fails.

Reading SUS (The Single Unix Specification) I see that it explicitly says:

"Upon successful completion, setlocale() shall return the string
associated with the specified category for the new locale. Otherwise,
setlocale() shall return a null pointer and the locale of the process is
not changed."

So the patch seems to be correct actually. We try to setlocale(LC_CTYPE,
"") to grab a locale from the environment to set LC_CTYPE, but we fail
for whatever, so we should just pass since we should not adjust LC_CTYPE.

Mmm, but it seems setlocale() in locale.py is not adhering to the
standard by not allowing the "" case properly. _parse_localename() is
being overly pedantic about this by raising a ValueError.

--

___
Python tracker 

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

[issue5883] detach() implementation

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Thanks for the review! New patch attached...

--
Added file: http://bugs.python.org/file13824/detach.patch

___
Python tracker 

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

[issue5890] Subclassing property doesn't preserve the auto __doc__ behavior

[George Sakkis]

New submission from George Sakkis :

Is the following behavior expected ?

class MyProp(property):
pass

class Foo(object):
@property
def bar(self):
'''Get a bar.'''

@MyProp
def baz(self):
'''Get a baz.'''


>>> print Foo.bar.__doc__ 
Get a bar.
>>> print Foo.baz.__doc__
None

--
messages: 86859
nosy: gsakkis
severity: normal
status: open
title: Subclassing property doesn't preserve the auto __doc__ behavior
type: behavior

___
Python tracker 

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

[issue5872] New C API for declaring Python types

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue5799] Change ntpath functions to implicitly support UNC paths

[Eric Smith]

Eric Smith  added the comment:

The doc patch doesn't apply cleanly for me.

There are a number of code cleanups in the patch, like 0->False,
1->True, the improvement of the params to path(), improvement in
isabs(), etc. I think these cleanups should be made in a separate patch,
so that it's easier to evaluate what's really involved in this change.
I'd be happy to do that, and produce the patches, if you could produce a
clean patch.

The docstring for splitdrive() should be indented, see PEP 257. Also,
the code snippet in that docstring is wrong, it uses 'split' where it
should be 'result', I think.

I haven't worked my way through all of the code and tests, yet.

--
nosy: +eric.smith

___
Python tracker 

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

[issue5891] strange list.sort() behavior on import, del and inport again

[David Stemmer]

New submission from David Stemmer :

Given two modules, I've seen the following kind of strange behavior with
list sorting on import and delete; a list that has been imported, sorted
and deleted remains sorted on a second import:

my_module.py:

some_list = ['b','a']

other_module.py:

from  my_module import some_list
print some_list
some_list.sort()
print some_list
del some_list
from  my_module import some_list
print some_list

Output is:

['b','a']
['a','a']
['a','b']

Sorry if it's already been reported.

--
files: bugs.rar
messages: 86861
nosy: dstemmer
severity: normal
status: open
title: strange list.sort() behavior on import, del and inport again
versions: Python 2.6
Added file: http://bugs.python.org/file13825/bugs.rar

___
Python tracker 

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

[issue5892] strange list.sort() behavior on import, del and inport again

[David Stemmer]

New submission from David Stemmer :

Given two modules, I've seen the following kind of strange behavior with
list sorting on import and delete; a list that has been imported, sorted
and deleted remains sorted on a second import:

my_module.py:

some_list = ['b','a']

other_module.py:

from  my_module import some_list
print some_list
some_list.sort()
print some_list
del some_list
from  my_module import some_list
print some_list

Output is:

['b','a']
['a','b']
['a','b']

Sorry if it's already been reported.

--
files: bugs.rar
messages: 86862
nosy: dstemmer
severity: normal
status: open
title: strange list.sort() behavior on import, del and inport again
versions: Python 2.6
Added file: http://bugs.python.org/file13826/bugs.rar

___
Python tracker 

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

[issue5891] strange list.sort() behavior on import, del and inport again

[David Stemmer]

Changes by David Stemmer :


Removed file: http://bugs.python.org/file13825/bugs.rar

___
Python tracker 

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

[issue5891] strange list.sort() behavior on import, del and inport again

[David Stemmer]

David Stemmer  added the comment:

EDIT: delete this, duplicate post

--

___
Python tracker 

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

[issue1648102] proxy_bypass in urllib handling of macro

[Senthil]

Senthil  added the comment:

I have fix this issue, in the revision 72155 for py2.7 and revision
72156 for py3k. 
Unfortunately, we have no tests for any proxy handling condition for
Windows and Darwin. This is a very specific case in the proxy handling;
thought let the fix be in (as per the MSDN spec), unittest coverage can
dealt separately.

--
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1 -Python 2.6

___
Python tracker 

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

[issue5891] strange list.sort() behavior on import, del and inport again

[Martin v. Löwis]

Changes by Martin v. Löwis :


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

___
Python tracker 

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

[issue5892] strange list.sort() behavior on import, del and inport again

[Martin v. Löwis]

Martin v. Löwis  added the comment:

That is not a bug in Python. The import statement merely adds a
reference to the list into your module, so both variables point to the
very same list (my_module.some_list is other_module.some_list).
Therefore, any changes made to the list through my_module will also
affect the list as seen from other_module.

Closing the report as invalid.

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

___
Python tracker 

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