[issue7180] "pydoc -k" can generate AttributeError on Mac OS X

[Kevin Grant]

New submission from Kevin Grant :

Running "pydoc -k ..." with a query string will end with a Python 
AttributeError while looking for Carbon.File.FSSpecType.

I was using /usr/bin/pydoc on Mac OS X Snow Leopard, which is from Python 2.6.1.

It appears that any query will produce a similar error, but here is one case:

  % pydoc -k example
  xxsubtype - xxsubtype is an example module showing how to subtype builtin 
types from C.
  doctest - Module doctest -- a framework for running examples in docstrings.
  Traceback (most recent call last):
File "/usr/bin/pydoc2.6", line 7, in 
  pydoc.cli()
File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py",
 line 2216, in cli
  apropos(val)
File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py",
 line 1911, in apropos
  ModuleScanner().run(callback, key)
File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py",
 line 1876, in run
  for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pkgutil.py",
 line 110, in walk_packages
  __import__(name)
File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-
scriptpackages/CodeWarrior/__init__.py", line 8, in 
  import aetools
File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aetools.py",
 line 36, in 
  from aepack import packkey, pack, unpack, coerce, AEDescType
File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aepack.py",
 line 61, in 
  FSSType = Carbon.File.FSSpecType
  AttributeError: 'module' object has no attribute 'FSSpecType'



A solution would appear to be as follows:

Since Carbon.File no longer defines FSSpecType, perhaps aepack.py should no 
longer support it.  This would require removing 
the definition from aepack.py:61, as well as the case in the pack() routine (at 
aepack.py:88-89) that uses FSSType.

--
assignee: ronaldoussoren
components: Macintosh
messages: 94307
nosy: kmgrant, ronaldoussoren
severity: normal
status: open
title: "pydoc -k" can generate AttributeError on Mac OS X
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

[issue7179] Unportable test(1) construct

[Ned Deily]

Changes by Ned Deily :


--
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

___
Python tracker 

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

[issue7119] email: msg.items() returns different values before and after msg.as_string()

[R. David Murray]

Changes by R. David Murray :


--
assignee: georg.brandl -> r.david.murray

___
Python tracker 

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

[issue7179] Unportable test(1) construct

[Thomas Klausner]

Thomas Klausner  added the comment:

That's against python-2.6.3. I see that Misc/build.sh automagically
linked from this bug report doesn't have this problem any longer (though
the other file still does).

--

___
Python tracker 

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

[issue7179] Unportable test(1) construct

[Thomas Klausner]

New submission from Thomas Klausner :

Mac/BuildScript/scripts/postflight.patch-profile and Misc/build.sh
contain the unportable bash(1) "==" comparison operator for test(1). It
is not supported by most other shells or even test(1) from GNU
coreutils. Please use "=" instead.

--
components: Build
files: test.1.patch
keywords: patch
messages: 94305
nosy: wiz
severity: normal
status: open
title: Unportable test(1) construct
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15170/test.1.patch

___
Python tracker 

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

[issue7119] email: msg.items() returns different values before and after msg.as_string()

[R. David Murray]

R. David Murray  added the comment:

Thinking about this further, it seems to me that it is in fact more
important that turning a message into a string produces the same result
no matter how many times it is called on the same (otherwise unmutated)
object than that it avoid mutating the object tree itself.  (This is
called idempotence and it is an important interface concept in certain
circumstances, and I think this is one of them).

The documentation should make the expectations clear, however.

--
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl
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

[issue1722344] Thread shutdown exception in Thread.notify()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch was committed in trunk, py3k and 3.1. Waiting for 2.6 to be
unfrozen before I commit it there too.

--
stage: commit review -> committed/rejected
status: open -> pending
versions:  -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

[issue7178] open function's buffering parameter is not completely doc'ed

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r75572.

--
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue6845] Restart support in binary upload for ftplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I think that a non-digit REST argument is an error. But I've tested some
> ftp servers and they don't return an error code, they just set REST to 0
> and return some OK code. Finally, ftplib doesn't check that, so if
> someone accidentally passes a non-digit argument it could be a difficult
> bug to spot.

What I mean is that integer arguments should be accepted as well, since
that's what is logical to produce.

--

___
Python tracker 

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

[issue7178] open function's buffering parameter is not completely doc'ed

[kuhnsjohn]

New submission from kuhnsjohn :

it says: "Pass 0 to switch buffering off (only allowed in binary mode),
1 to set line buffering, and an integer > 1 for full buffering."

The last section should say something like: "and an integer > 1 to
specify the buffer size for full buffering."

--
assignee: georg.brandl
components: Documentation
messages: 94300
nosy: georg.brandl, kuhnsjohn
severity: normal
status: open
title: open function's buffering parameter is not completely doc'ed
type: feature request
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

[issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I'm not sure that changing this would do any good. Applications may rely
on the status quo, so I fail to see the point in breaking them.

--

___
Python tracker 

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

[issue7170] subclasses of (some) built-in types are not weakref-able

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

That's fair.  I suggest the following change:

current text:
"Several built-in types such as list and dict do not directly support
weak references but can add support through subclassing:"

new text:
"Several built-in types such as list and dict do not directly support
weak references but can add support through subclassing, as shown below.
 Other built-in types such as tuple and int do not support weak
references even when subclassed."

--

___
Python tracker 

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

[issue7177] Unclear warning for subprocess.call

[Christopher Jefferson]

New submission from Christopher Jefferson :

I wandered across subprocess.call as it was mentioned as a replacement for 
os.system. The 
following large warning is attached to it:

Warning Like Popen.wait(), this will deadlock if the child process generates 
enough output to a 
stdout or stderr pipe such that it blocks waiting for the OS pipe buffer to 
accept more data.

This scared my off completely, and I assumed the function was simply broken, as 
I assumed 
"stdout pipe" just meant that wherever stdout was sent by default.

I now believe this warning only applies if 'stdout=PIPE', or similar, is used 
explicitally.

Could this warning be better worded, perhaps adding "if stdout or stderr are 
explicitly 
redirected", as in:

Warning Like Popen.wait(), if stdout or stderr are explicitly redirected this 
will deadlock if 
the child process generates enough output to a stdout or stderr pipe such that 
it blocks 
waiting for the OS pipe buffer to accept more data.

--
assignee: georg.brandl
components: Documentation
messages: 94297
nosy: azumanga, georg.brandl
severity: normal
status: open
title: Unclear warning for subprocess.call
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

[issue7176] sum() doesn't work for lists.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

One use of the start argument is used to specify an initial zero/metpy
value for the summation:  0  or  0.0   or Decimal(0)  or  [].

BTW, sum() isn't a good technique for concatenating lists.  Instead use
something like:

   result = []
   for seq in data:
  result.extend(seq)

A fast one-liner version:
   result = list(itertools.chain.from_iterable(seq))

--
nosy: +rhettinger

___
Python tracker 

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

[issue7176] sum() doesn't work for lists.

[Björn Augustsson]

Björn Augustsson  added the comment:

Er, that's fairly weird...

Couldn't it do eg "type(first argument)", and if it's a list, 
replace the 0 with []?

What's the second argument's use anyway?
  s = sum([1,2,3,4]) + 3
seems a lot clearer than
  s = sum([1,2,3,4], 3)
and those seem to be equivalent.

Thanks,
/August.

--

___
Python tracker 

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

[issue6845] Restart support in binary upload for ftplib

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

The patch looks good to me.
Only two little remarks:

1: I'd create two new separate tests rather than appending them to
existent ones.

2: > self.client.retrbinary('retr', received.append, rest=str(rest))

str() should be useless here.

> According to the RFC, the argument to REST can be any string of
> printable characters. However, does it happen for clients to put
> non-digits in there?

It shouldn't happen but in any case I woulnd't want ftplib to check for
such a kind of thing.
Deciding whether the REST argument is invalid is up to the server, in
which case it will send a 4xx/5xx error response.

> But I've tested some ftp servers and they don't return an
> error code, they just set REST to 0 and return some OK code.

IMHO a bad design choice.

--

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Tarek Ziadé wrote:
> 
> Tarek Ziadé  added the comment:
> 
> I like ~/.python very much too (that was my initial proposal IIRC). 

+1 on that name as well.

One thing to note though: it is well possible that a user uses
multiple Python versions. With just one such directory, all
versions would look in the same directory for the configuration
files and this could lead to incompatibilities, e.g. Python 2.7
might not like that Python 3.6 needs in some config file (for
whatever reason).

> Now for the global distutils.cfg, if we want to have it somewhere else
> that the distutils package directory itself, we would need a
> "/etc/python" scheme for instance, that could be also added in site.py.
>
> I don't know though how the latter would look under windows

I think Subversion get's this pretty right, so we might want
to follow their scheme:

http://svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1

--

___
Python tracker 

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

[issue6845] Restart support in binary upload for ftplib

[Pablo Mouzo]

Pablo Mouzo  added the comment:

I think that a non-digit REST argument is an error. But I've tested some
ftp servers and they don't return an error code, they just set REST to 0
and return some OK code. Finally, ftplib doesn't check that, so if
someone accidentally passes a non-digit argument it could be a difficult
bug to spot.

--

___
Python tracker 

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

[issue1722344] Thread shutdown exception in Thread.notify()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, I'll do it then!

--
assignee:  -> pitrou

___
Python tracker 

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

[issue1722344] Thread shutdown exception in Thread.notify()

[Adam Olsen]

Adam Olsen  added the comment:

Nope, no access.

--

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Tarek Ziadé]

Tarek Ziadé  added the comment:

I like ~/.python very much too (that was my initial proposal IIRC). 

I guess the best way to add this support is to provide a new api in
site.py, that returns this folder.

Distutils can move pypirc and distutils.cfg file there.

Now for the global distutils.cfg, if we want to have it somewhere else
that the distutils package directory itself, we would need a
"/etc/python" scheme for instance, that could be also added in site.py.

I don't know though how the latter would look under windows

--
nosy: +barry, lemburg

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The distutils.cfg file is located in the distutils package itself !
> 
> So the target is ~/.local/pythonX.X/site-packages/distutils/distutils.cfg

Ah, that's horrible. -1 to that.
Configuration files should be easily findable by skimming through the
dot-files in the user's directory. ~/.python fulfills that condition.

--

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> Well, that makes it the user-specific equivalent of /usr or /usr/local.
> Do you put your configuration files in /usr/local ? 
> Why put them in .local ?

The distutils.cfg file is located in the distutils package itself !

So the target is ~/.local/pythonX.X/site-packages/distutils/distutils.cfg

(sorry if that was unclear)

Now, I would totally agree to have a better ~/.NAME to reunite
user-specific *configuration* file for Python, but that would be yet
another directory for user-specific Python files.

--

___
Python tracker 

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

[issue6845] Restart support in binary upload for ftplib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

According to the RFC, the argument to REST can be any string of
printable characters. However, does it happen for clients to put
non-digits in there?
(that is, are there any implementations where the argument to REST is
something else than the byte offset from the start of file?)

--

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[R. David Murray]

R. David Murray  added the comment:

+1 to what Antoine said.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I've read the thread now and I think the original proposal of having a
~/.python was more sensible and more user-friendly.

--

___
Python tracker 

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

[issue1722344] Thread shutdown exception in Thread.notify()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The patch looks good to me.
And since Py_Finalize() claims to "destroy all sub-interpreters" and
"free all memory allocated by the Python interpreter", I guess your
approach makes sense. Can you commit?

--
resolution:  -> accepted
stage: patch review -> commit review
versions: +Python 3.2 -Python 3.0

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> That's what is returned by site.getuserbase()
> 
> (which uses PYTHONUSERBASE, and defaults to ~/.local)

Well, that makes it the user-specific equivalent of /usr or /usr/local.
Do you put your configuration files in /usr/local ? Why put them
in .local ?

> PYTHONUSERBASE is the root of Python user-specific paths so it makes
> sense to have all Python related files in there.

That doesn't make sense actually, since .local isn't Python-specific. :)

--

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Tarek Ziadé]

Tarek Ziadé  added the comment:

That's what is returned by site.getuserbase()

(which uses PYTHONUSERBASE, and defaults to ~/.local)

PYTHONUSERBASE is the root of Python user-specific paths so it makes
sense to have all Python related files in there.

This came up with the discussion we had with others at Distutils-SIG

read this thread here for more info:
http://mail.python.org/pipermail/distutils-sig/2009-August/012865.html

[.]pypirc should probably go there too.

--
type:  -> feature request

___
Python tracker 

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

[issue6845] Restart support in binary upload for ftplib

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux

[Antoine Pitrou]

Antoine Pitrou  added the comment:

x86-64 is now the common name for the 64-bit instruction set implemented
by mainstream AMD and Intel processors. Even on the AMD web site,
"x86-64" shows up more often than "AMD64" (says Google).

--
nosy: +pitrou

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Why is this? .local/ contains machine-installed files while
.pydistutils.cfg is edited by the user.

--
nosy: +pitrou

___
Python tracker 

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

[issue7048] decimal.py: logb: round the result if it is greater than prec

[Mark Dickinson]

Mark Dickinson  added the comment:

Sorry;  ignore that last.  I was confused by the fact that the _check_nans 
call came before the 'if context is None' test.  But _check_nans deals 
correctly with a context of None, so logb is fine.

--

___
Python tracker 

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

[issue7048] decimal.py: logb: round the result if it is greater than prec

[Mark Dickinson]

Mark Dickinson  added the comment:

I just want to note another problem with logb:  it doesn't use the correct 
context when processing NaNs.  This needs a test and a fix.

--

___
Python tracker 

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

[issue7176] sum() doesn't work for lists.

[Mark Dickinson]

Mark Dickinson  added the comment:

To sum lists, you need to supply a second argument to sum:

>>> sum([[1, 2], ['x', 'y']], [])
[1, 2, 'x', 'y']

The default value of the second argument is 0, which is why you're seeing 
the TypeError.

--
nosy: +mark.dickinson
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

[issue7176] sum() doesn't work for lists.

[Björn Augustsson]

New submission from Björn Augustsson :

Summary: "sum()" doesn't work on lists, even though the docs says it 
should.

The docs say:

"Note that sum(range(n), m) is equivalent to reduce(operator.add, 
range(n), m)"

That's not true.

import operator

a=[1,2]
b=["x","y"]

reduce(operator.add, [a,b])
# Works, gives "[1, 2, 'x', 'y']" as expected.

sum ([a,b])
# Does not work, gives: "TypeError: unsupported operand type(s) for +: 
'int' and 'list'"

(And "a + b" obviously works too.)

/August.

--
components: None
messages: 94275
nosy: oggust
severity: normal
status: open
title: sum() doesn't work for lists.
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

[issue7099] Decimal.is_normal should return True even for numbers with exponent > Emax

[Mark Dickinson]

Mark Dickinson  added the comment:

Fixed in r75561 (trunk), r75662 (py3k) and r75663 (release31-maint).
release26-maint is still frozen; leaving open for the backport.

--
resolution:  -> fixed
versions:  -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

[issue6672] Add Mingw recognition to pyport.h to allow building extensions

[Jan Schlüter]

Jan Schlüter  added the comment:

Hello!

Thanks, you're right. I have created a patch against the latest SVN 
revision (75557) of branches/release26-maint/Include/pyport.h. The 
patch also applies fine to trunk/Include/pyport.h.
As it applies to both versions, I have created the patch directly from 
inside the Include directory rather than from the svn root.

As I am abroad for a couple of months and do not have access to my 
Windows machine, I currently cannot test the patch (i.e. compile Python 
on Windows using Mingw), but I successfully compiled the PyMedia 
package using Mingw and the modified pyport.h.

Please let me know if you have any questions or remarks!

--
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file15169/pyport-issue6672.diff

___
Python tracker 

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

[issue7175] unify pydistutils.cfg and distutils.cfg and use .local

[Tarek Ziadé]

New submission from Tarek Ziadé :

[.]pydistutils.cfg will be deprecated in favor of a single
"distutils.cfg", located in .local/ alongside the files added for
example by the per user-site packages.

--
assignee: tarek
components: Distutils
messages: 94272
nosy: tarek
priority: normal
severity: normal
status: open
title: unify pydistutils.cfg and distutils.cfg and use .local
versions: 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

[issue7174] modeule: queue class: PriorityQueue

[R. David Murray]

R. David Murray  added the comment:

In python3 (unlike 2) objects are by default unorderable.  You'll need
to define an ordering for your objects in order to use them in a
PriorityQueue, whether or not they are inside a tuple.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[issue7174] modeule: queue class: PriorityQueue

[Andrew Shuiu]

New submission from Andrew Shuiu :

Puting 2 tuples like (100, data1), (100, data2) in a PriorityQueue
generates an builtins.TypeError: unorderable types: data1 < data2

Code which generates error:
theQueue.put((100, object1()),True)
theQueue.put((100, object1()),True)

Snippet from error:
builtins.TypeError: unorderable types: Crawler() < Crawler()
File "d:\work\python\gglcrwl.py", line 89, in 
  crawlGroup.Process()
File "d:\work\python\GglCrwLib.py", line 1056, in Process
  globs.linksQueue.put((globs.cDefLinkPriority,
Crawler(u.title_url,ca)),True)
File "C:\Program Files\Python31\Lib\queue.py", line 153, in put
  self._put(item)
File "C:\Program Files\Python31\Lib\queue.py", line 242, in _put
  heappush(self.queue, item)

--
components: Library (Lib)
messages: 94270
nosy: asuiu
severity: normal
status: open
title: modeule: queue class: PriorityQueue
type: crash
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

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

[Stefan Behnel]

Stefan Behnel  added the comment:

I should add that the crash doesn't necessarily happen during the first
test run, which also converts the Cython source to Py3 using 2to3.
However, once that's done, running the test a second time crashes reliably.

--

___
Python tracker 

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

[issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2

[Stefan Behnel]

New submission from Stefan Behnel :

Running the Cython compiler under Python 3.1.1 and 3.2 (SVN) corrupts
PyThreadState->exc_value by leaving a dead reference. Printing the value
then leads to a crash.

This bug is about plain Python code, no Cython built extension modules
involved.

Steps to reproduce the problem:

- get Cython from http://hg.cython.org/cython-devel (see the bz2/zip/gz
links on the left to get an archive without doing a checkout)

- apply the attached patch, which simply prints sys.exc_info() during
the compiler run at a place where it's known to be corrupted

- execute the following to run a single test in the test suite:

   python3.1 runtests.py --no-cpp --no-pyregr --no-doctest -vv \
  'compile\.first_assignment'

- expect a crash after printing "HERE1"

Before exc_info gets corrupted, we make heavy use of generators to
traverse the parse tree (see Cython/Compiler/TreePath.py), while being
inside of a recursive traversal of the tree already (see the
"VisitorTransform" class and its base class in
Cython/Compiler/Visitor.py). The code section that links the two is in
the class "TreeAssertVisitor" at the end of Cython/TestUtils.py, where
the patch applies. As exc_info doesn't get corrupted during the normal
recursive tree transformation traversals before that, the generator
usage in TreePath.py is likely related to the crash.

The crash was found and reproduced under two different Linux x86 systems.

--
components: Interpreter Core
files: crash-patch.patch
keywords: patch
messages: 94268
nosy: scoder
severity: normal
status: open
title: Cython compiler run crashes CPython 3.1.1 and 3.2
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15168/crash-patch.patch

___
Python tracker 

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