[issue5788] datetime.timedelta is inconvenient to use...

[Mark Dickinson]

Mark Dickinson  added the comment:

A late note: this would be redundant if the oft-requested division of 
timedeltas were implemented:  t.total_seconds could then be spelt

t/timedelta(seconds=1)

with the advantage that there would then be a natural way to spell 
t.total_days or t.total_hours as well.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue5788] datetime.timedelta is inconvenient to use...

[Mark Dickinson]

Mark Dickinson  added the comment:

That should be t.total_seconds(), of course.

--

___
Python tracker 

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

[issue1023290] Conversion of longs to bytes and vice-versa.

[Mark Dickinson]

Mark Dickinson  added the comment:

Looks good to me, too.

--

___
Python tracker 

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

[issue1023290] Conversion of longs to bytes and vice-versa.

[Mark Dickinson]

Mark Dickinson  added the comment:

All tests pass on OS X 10.5/Intel, except that I'm still getting the issue 
6687 test failure.  This needs to be resolved somehow before committing.

--

___
Python tracker 

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

[issue4057] Popen(..., cwd=...) does not set PWD environment variable

[Geoffrey Bache]

Changes by Geoffrey Bache :


--
nosy: +gjb1002

___
Python tracker 

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

[issue7397] __import__ docs should reference imputil.import_module

[Nick Coghlan]

New submission from Nick Coghlan :

Fairly straightforward one - __import__ is no longer the preferred tool
for doing runtime imports, so its documentation should point to
imputil.import_module

(this is a little more than just a "see also", some of the existing
wording in the first few paragraphs should also be tweaked)

--
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 95736
nosy: georg.brandl, ncoghlan
severity: normal
status: open
title: __import__ docs should reference imputil.import_module
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

[issue6727] ImportError when package is symlinked on Windows

[Nick Coghlan]

Nick Coghlan  added the comment:

Given that you had to use ctypes to create the symlinks on Windows in
the first place, I'd say you're right :)

Probably the first step would be to make sure the nt OS and path modules
get Windows symlink support (although even that may not be enough, due
to the bootstrapping issues with file access and the import machinery).

--
nosy: +ncoghlan

___
Python tracker 

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

[issue7397] __import__ docs should reference imputil.import_module

[Eric Smith]

Eric Smith  added the comment:

According to http://docs.python.org/library/imputil.html, imputil is
deprecated and it has been removed in 3.x. Further, I don't see
import_module in imputil (2.6 or trunk), it's just an example on that
documentation page.

--
nosy: +eric.smith

___
Python tracker 

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

[issue7397] __import__ docs should reference importlib.import_module

[Nick Coghlan]

Nick Coghlan  added the comment:

s/imputil/importlib/

Details, details...

--
title: __import__ docs should reference imputil.import_module -> __import__ 
docs should reference importlib.import_module

___
Python tracker 

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

[issue5788] datetime.timedelta is inconvenient to use...

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> A late note: this would be redundant if the oft-requested division of 
> timedeltas were implemented:  t.total_seconds could then be spelt
> 
> t/timedelta(seconds=1)

It would be less obvious, though.

--

___
Python tracker 

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

[issue7398] Issue with _PyLong_Format while trying to build Python on HP-UX itanium

[Paul H]

New submission from Paul H :

Hello all,

First post here so go easy on me please! And please bear in mind I am
not a C programmer, just a unix admin trying to build python as an
option for other programmers to use.

I am trying to build Python 3.1.1 on HP-UX itanium. OS and compiler
details are as follows:

HP-UX  B.11.31 U ia64 2812253632 unlimited-user license
aCC: HP C/aC++ B3910B A.06.23 [May 18, 2009]

So far, with the help of this forum and documentation from this and
previous versions of Python, I have been working through the process as
follows:

export CC="/opt/aCC/bin/aCC -Ae +DD64"
export CFLAGS="-Ae +DD64"
export CXX="/opt/aCC/bin/aCC -Ae"
export CXXFLAGS="-Ae +DD64"
export LDFLAGS="+DD64 -L/usr/local/bzip2-1.0.3/lib"
./configure --prefix=/python/3.1.1 --without-gcc

unset CC CFLAGS CXX CXXFLAGS LDFLAGS
make

I've been working through the various errors I've been getting as best I
can and have hit one that I don't think I can progress:

"Python/../Objects/stringlib/formatter.h", line 1369: error #2140: too many
  arguments in function call
  return _PyLong_Format(value, base, 0, 1);

It looks like _PyLong_Format is defined in Objects/longobject.c.

Any ideas on how to progress this one, or indeed any tips to get a
successful build on my architecture, would be much appreciated.

Many thanks,
Paul.

--
components: Build
messages: 95741
nosy: paulh_irl
severity: normal
status: open
title: Issue with _PyLong_Format while trying to build Python on HP-UX itanium
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

[issue7398] Issue with _PyLong_Format while trying to build Python on HP-UX itanium

[Eric Smith]

Eric Smith  added the comment:

For 3.1, line 1369 of Python/../Objects/stringlib/formatter.h should not
be used. There's a #if on line 1359 that prevents the long_format
function from being used. Could you investigate why that #if is using
the wrong value?

--
nosy: +eric.smith

___
Python tracker 

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

[issue7398] Issue with _PyLong_Format while trying to build Python on HP-UX itanium

[Martin v . Löwis]

Martin v. Löwis  added the comment:

To elaborate on Eric's suggestion, put a single line

top PY_VERSION_HEX bottom

right above the line 

#if PY_VERSION_HEX >= 0x0300

Then add the flag that produces preprocessor output to the compiler line
(copy the compiler line literally from the build process). Most likely,
you'll have to replace the -c option with either -P or -E; search the
output for the top/bottem pattern, and report the value of PY_VERSION_HEX.

--
nosy: +loewis

___
Python tracker 

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

[issue5725] process SysV-Semaphore support

[Philip Semanchuk]

Philip Semanchuk  added the comment:

I stumbled across this bug report while looking for an mmap-related
issue. I thought I'd mention that I have a module for SysV IPC that's
about a year old. 

Obviously it's not in the standard library, but it is pretty well
fleshed out. It's in active use and I consider it fairly well debugged. 

It's for Python 2.x only.

http://semanchuk.com/philip/sysv_ipc/

Hope this helps

--
nosy: +osvenskan

___
Python tracker 

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

[issue7398] Issue with _PyLong_Format while trying to build Python on HP-UX itanium

[Paul H]

Paul H  added the comment:

Hi all,

Many thanks for the tips, and for the super-quick responses also! 

Yes indeed, what is happening here is that PY_VERSION_HEX is not being
evaluated correctly. In fact what appears to be happening is that
Include/patchlevel.h is not being considered in the compile despite
"-IInclude" being on the compiler command line. Perhaps I have a
compiler issue. I'll work it from here.

Thanks again for your help.
Paul.

--

___
Python tracker 

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

[issue7398] Issue with _PyLong_Format while trying to build Python on HP-UX itanium

[Eric Smith]

Eric Smith  added the comment:

I'm going to close this, but if you find the problem (and especially if
you develop a patch to resolve it), please post back here.

--
status: open -> closed

___
Python tracker 

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

[issue4057] Popen(..., cwd=...) does not set PWD environment variable

[Ronald Oussoren]

Ronald Oussoren  added the comment:

In most shells $PWD is a magic variable that is maintained by the shell 
itself. 

IMHO python has no reason to mess with variables that happen to be defined 
by some shells. If subprocess were to set $PWD, os.setuid should set $UID, 
and there may be other magic variables as well.

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I agree that a proper solution might include full symlink support.

However, symlink support for windows (issue1578269) is taking some time
to develop and will likely never be available for Python 2.

My feeling is that a symlink naive implementation (such as Python is
now), should treat symlinks in a naive manner -- that is, treat them as
regular files and directories and let the OS perform the abstraction.

I hope to begin investigating this after I've closed out issue1578269,
although I'd be happy if someone else wanted to address this issue
beforehand.

If it's possible to address this in a straightforward way independent of
a symlink-aware Python interpreter, that would be desirable.

--

___
Python tracker 

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

[issue7399] Possible bug in Python Tutorial

[David Henretty]

New submission from David Henretty :

Hi,

In the v3.1.1 Python Tutorial (section 10.7 - Internet Access), the 
sample code (shown below) results in the following error :-

from urllib.request import urlopen
for line in urlopen('http://tycho.usno.navy.mil/cgi-bin/timer.pl'):
 if 'EST' in line or 'EDT' in line:
 print(line)

Traceback (most recent call last):
  File "", line 2, in 
TypeError: Type str doesn't support the buffer API

I presume this has something to do with the assumed type of the 
variable 'line', but I am very new to Python.

Replacing the 'if' line with the following DOES work :-

 if 'EST' in str(line) or 'EDT' in str(line):

Can anyone confirm / explain this ?

Thanks,

DH

--
assignee: georg.brandl
components: Documentation
messages: 95749
nosy: dh, georg.brandl
severity: normal
status: open
title: Possible bug in Python Tutorial
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

[issue7399] Possible bug in Python Tutorial

[R. David Murray]

R. David Murray  added the comment:

The example is indeed wrong.  urlopen is returning an object that emits
binary data.  The error comes from using 'in' on incompatible types. 
The solution is to encode the data with an appropriate encoding, once
you figure out what that is.

--
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch
type: compile error -> behavior
versions: +Python 3.2

___
Python tracker 

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

[issue4057] Popen(..., cwd=...) does not set PWD environment variable

[Geoffrey Bache]

Geoffrey Bache  added the comment:

I can see your point, though I think particularly in this case it's
(unfortunately) fairly common that scripts on POSIX platforms read $PWD
instead of finding the current working directory properly. 

I'm probably not the first person that has had to set PWD explicitly in
a python program for this reason. Yes, it's really the fault of the
people who maintain the script I'm calling, but I don't think setting
PWD on POSIX could have any bad effects and should surely be easy to do?

--

___
Python tracker 

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

[issue7400] Small typo in Python's library documentation: set

[Renato Cunha]

New submission from Renato Cunha :

In the documentation of the built-in functions, the description of set
says "Return a new set, optionally with elements ARE taken from
iterable. ...".

The referenced text should be either "... optionally with elements taken
from iterable. ...".

--
assignee: georg.brandl
components: Documentation
files: set-typo-fix.diff
keywords: patch
messages: 95752
nosy: georg.brandl, trovao
severity: normal
status: open
title: Small typo in Python's library documentation: set
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15399/set-typo-fix.diff

___
Python tracker 

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

[issue7400] Small typo in Python's library documentation: set

[Georg Brandl]

Georg Brandl  added the comment:

Thanks, fixed in r76538.

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

[issue7397] __import__ docs should reference importlib.import_module

[Brett Cannon]

Changes by Brett Cannon :


--
nosy: +brett.cannon

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

Now that FTP_TLS has been integrated into the trunk, the patch should be
augmented in order to also cover that class. Right now a test is failing:

==
ERROR: test_storbinary_rest (test.test_ftplib.TestTLS_FTPClassMixin)
--
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_ftplib.py", line
485, in test_storbinary_rest
self.client.storbinary('stor', f, rest=r)
TypeError: storbinary() got an unexpected keyword argument 'rest'

Apart from that, the patch looks ok.

--

___
Python tracker 

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

[issue7401] os.write and os.close on pipe from separate threads hangs on Mac OS X

[Hugh Secker-Walker]

New submission from Hugh Secker-Walker :

The attached script demonstrates a problem on Mac OS X 10.5 whereby
Python can hang while simultaneously trying os.write with a large buffer
and os.close, from separate threads on the write and read fds
respectively of a pipe.

--
components: IO
files: os_pipe_write_close_bug.py
messages: 95755
nosy: hughsw
severity: normal
status: open
title: os.write and os.close on pipe from separate threads hangs on Mac OS X
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15400/os_pipe_write_close_bug.py

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

Changes by Pablo Mouzo :


Removed file: http://bugs.python.org/file15302/issue6845-trunk.diff

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

Thanks Antoine, I'm attaching both patches. Now the test isn't failing.

--
Added file: http://bugs.python.org/file15401/issue6845-trunk.diff

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

Changes by Pablo Mouzo :


Added file: http://bugs.python.org/file15402/issue6845-py3k.diff

___
Python tracker 

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

[issue1578269] Add os.link() and os.symlink() and os.path.islink() support for Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Thanks Eric for the report. I had tested earlier on XP, but didn't do so
with the latest changes. It appears that a couple of modules didn't
behave well under XP. The latest patch (16) addresses these issues. In
particular, many tests use the presence of os.symlink to presume
symbolic link support, but under Windows XP, os.symlink exists but
raises a NotImplementedError when called. To address this, I added
test.support.has_symlink function which can be used to determine whether
the OS has symlink support (and not just a symlink function).

This raises the issue that it might be worthwhile to remove the symlink
and readlink methods at the os module init time if symlinks aren't
supported on the OS.

For now, this implementation should be adequate to move forward.

--
Added file: http://bugs.python.org/file15403/windows symlink draft 16.patch

___
Python tracker 

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

[issue7401] os.write and os.close on pipe from separate threads hangs on Mac OS X

[Hugh Secker-Walker]

Changes by Hugh Secker-Walker :


--
versions: +Python 2.5

___
Python tracker 

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

[issue7401] os.write and os.close on pipe from separate threads hangs on Mac OS X

[Hugh Secker-Walker]

Changes by Hugh Secker-Walker :


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

[issue4057] Popen(..., cwd=...) does not set PWD environment variable

[Ronald Oussoren]

Ronald Oussoren  added the comment:

On 26 Nov, 2009, at 19:27, Geoffrey Bache wrote:

> 
> Geoffrey Bache  added the comment:
> 
> I can see your point, though I think particularly in this case it's
> (unfortunately) fairly common that scripts on POSIX platforms read $PWD
> instead of finding the current working directory properly. 
> 
> I'm probably not the first person that has had to set PWD explicitly in
> a python program for this reason. Yes, it's really the fault of the
> people who maintain the script I'm calling, but I don't think setting
> PWD on POSIX could have any bad effects and should surely be easy to do?

Shouldn't the script set $PWD itself? AFAIK shells like bash will set $PWD 
regardless of whether they are running as an interactive shell or as a 
shellscript.

Reading os.environ['PWD'] in a Python script not a good example of whey the 
proposed functionality might be useful because there are a number of ways to 
change the current working directory without affecting os.environ. For example 
using os.chdir, or even an extensions that calls the chdir system call directly.

Ronald

--
Added file: http://bugs.python.org/file15404/smime.p7s

___
Python tracker 

___

smime.p7s
Description: S/MIME cryptographic signature
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7401] os.write and os.close on pipe from separate threads hangs on Mac OS X

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Why do you think this is a bug in Python, and not an operating system
bug? I.e. if you would redo the script in C, would it still hang?

--
nosy: +loewis

___
Python tracker 

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