[issue1321] TimedRotatingFileHandler logic for day of week is wrong

[Moshe Cohen]

Changes by Moshe Cohen:


--
components: None
nosy: mosheco
severity: major
status: open
title: TimedRotatingFileHandler logic for day of week is wrong
type: behavior
versions: Python 2.4

__
Tracker <[EMAIL PROTECTED]>

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

[issue1321] TimedRotatingFileHandler logic for day of week is wrong

[Moshe Cohen]

New submission from Moshe Cohen:

The logic for determining the time till midnight on the requested day of
week is reversed.
>From logging/handlers.py:234 

if day > self.dayOfWeek:
daysToWait = (day - self.dayOfWeek) - 1
self.rolloverAt = self.rolloverAt + (daysToWait *
(60 * 60 * 24))
if day < self.dayOfWeek:
daysToWait = (6 - self.dayOfWeek) + day
self.rolloverAt = self.rolloverAt + (daysToWait *
(60 * 60 * 24))

The two cases are reversed. 'day' is the current day. 'self.dayOfWeek'
is the desired day.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1321] TimedRotatingFileHandler logic for day of week is wrong

[Moshe Cohen]

Moshe Cohen added the comment:

The comments before the code are correct, by the way.
The code should do exactly that.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1321] TimedRotatingFileHandler logic for day of week is wrong

[Georg Brandl]

Changes by Georg Brandl:


--
assignee:  -> vsajip
nosy: +vsajip

__
Tracker <[EMAIL PROTECTED]>

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

[issue1298] Support for z/OS and EBCDIC.

[Lauri Alanko]

Lauri Alanko added the comment:

The port is certainly not yet "complete" in any sense. I have only fixed
the most obvious places where explicit conversion between ASCII/Unicode
values and platform-specific characters is required. There are a number
of remaining issues, some of which cannot be fixed without major
rehauls. The point of this first release is just to allow other
interested people to chime in, to test the patch, and to suggest what
should be done with it. The latter has certainly happened. :)

I have no great interest in whether the patch ever gets incorporated
into the main Python distribution. I do think, though, that it's a good
idea to make the relationship between characters and Unicode values more
explicit in the code in any case, and my patch shouldn't affect the
behavior on any other platforms.

Guido's comment about networking code is quite accurate, but the problem
is social, not technical: there is already networking code that assumes
that 8-bit string literals represent ASCII strings, and there is already
text-processing code that assumes that 8-bit string literals represent
"text" as found in ordinary text files on the platform. There is no
reliable way to make both kinds of code work on a platform whose native
encoding is not ASCII-compatible. In this sense, it is indeed impossible
to port Python 2.x to an EBCDIC platform "completely", so that all
existing code would continue to do "the right thing" without modifications.

However, Py3k presents a fresh start, and one where this particular
problem is gone, since string literals are no longer associated with a
particular encoding, and bytes literals explicitly represent the ASCII
values of the characters in the literal expression. Then text-processing
code will likely use string literals, and it easy to make the default
encoding platform-specific when transferring data between local text
files and string objects. As far as I can see, EBCDIC shouldn't pose any
special problems then.

>From what I read in PEP 3120 and the Py3k docs, there seems to be some
confusion regarding source encoding issues.

Firstly, Python source code is fundamentally _text_. For instance, a
string literal is delimited by single quote or double quote characters.
Characters themselves are abstract entities that have no inherent
numeric values, although we can name them with e.g. Unicode code points,
so we can say that the string delimiters are characters represented by
the code points U+0022 and U+0027.

What PEP 3120 specifies is a mechanism for mapping octet sequences into
these abstract characters. If this is made part of the language
specification, it presumably means that a conformant Py3k source file
must start as UTF-8 at least until an encoding declaration is
encountered. Further, a conformant Py3k implementation must accept such
UTF-8 source files and decode them as specified in the PEP.

So far so good. however, there is nothing to prevent an implementation
from providing (as an extension) a facility to allow _other_ kinds of
source as well. "There is no room for platform-specific derivations" is
an arbitrary restriction: there are certainly quite a number of ways to
support both UTF-8 and CP1047 source on z/OS: for instance, the
filesystem allows storing the encoding of a text file as metadata.

Moreover, there is a semantics-preserving mapping from UTF-8 source
files to CP1047 source files: since non-ASCII characters can only appear
in comments an string literals, and comments have no semantics, it
suffices to \u-escape the exotic characters in string literals. Hence
all Python source can be represented as native text on an EBCDIC
platform.

Of course you can declare that support for such extensions would be
heretical and no EBCDIC source file would be True Python Source and no
EBCDIC implementation would be a True Python Implementation, but I don't
really care. Python 3000 _can_ be ported to z/OS much better than 2.x,
and it probably will, even if you don't like it. Oh the wonders of open
source. :)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1321] TimedRotatingFileHandler logic for day of week is wrong

[Vinay Sajip]

Vinay Sajip added the comment:

Fixed checked into trunk: r58628. Also checked into release25-maint.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1778443] robotparser.py fixes

[Aristotelis Mikropoulos]

Aristotelis Mikropoulos added the comment:

Yes, of course I meant spaces on both sides of ">=", it was just a typo
of mine. I am sorry. I am glad you recommend applying my patch. I hope
it helps.

--
nosy: +Indy

_
Tracker <[EMAIL PROTECTED]>

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

[issue419903] Non-contiguous indexing and slicing

[Facundo Batista]

Facundo Batista added the comment:

The idea is rejected, so I close the bug.

If wanted, push further discussion of this in the lists.

--
nosy: +facundobatista
status: open -> closed


Tracker <[EMAIL PROTECTED]>


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

[issue1298] Support for z/OS and EBCDIC.

[Guido van Rossum]

Guido van Rossum added the comment:

I have no desire or time to continue this discussion.  The ASCII
assumption will be ingrained as deeply or deeper in 3.0 than in 2.x,
just like 8-bit bytes and 2's complement.  The computer industry has
chosen, and there just isn't any incentive to invent abstractions for
properties that are constant in 99.99% of all practical situations.

--
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue588756] python should obey the FHS

[Facundo Batista]

Facundo Batista added the comment:

Added to the PEP 42, rev 58638.

--
nosy: +facundobatista
status: open -> closed


Tracker <[EMAIL PROTECTED]>


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

[issue1290] xml.dom.minidom not able to handle utf-8 data

[Facundo Batista]

Changes by Facundo Batista:


Removed file: http://bugs.python.org/file8559/unnamed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1290] xml.dom.minidom not able to handle utf-8 data

[Facundo Batista]

Changes by Facundo Batista:


Removed file: http://bugs.python.org/file8560/unnamed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1322] platform.dist() has unpredictable result under Linux

[Yann Cointepas]

New submission from Yann Cointepas:

The distribution name returned by platform.dist() depends on the order
of os.path.listdir( '/etc' ). It selects the first file matching the
regex r'(\w+)[-_](release|version)' and takes part of the file name
(i.e. matchResult.groups()[0]) as distribution name. But there are often
several files matching this pattern (at least on Fedora and Mandriva).
For instance, on a Mandriva 2007.1 official, I can see the following files:

[EMAIL PROTECTED] ~]$ ls -l /etc/*-release
-rw-r--r-- 1 root root 137 jan 18  2007 /etc/lsb-release
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/mandrakelinux-release ->
mandriva-r 
  elease
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/mandrake-release ->
mandriva-releas
   e
-rw-r--r-- 1 root root  50 avr  2  2007 /etc/mandriva-release
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/redhat-release ->
mandriva-release

Therefore, the result for platform.distrib()[0] could be mandriva,
mandrake, redhat or even lsb. The first match wins !

Ignoring symlinks could remove part of the problem. On Mandriva, it
would leave only lsb-release and mandriva-release. It is possible to
select the good one by ignoring lsb-release or by verifying the file's
content (mandriva-release has one line and lsb-release has several
lines). I do not know if the second method is portable.

--
messages: 56710
nosy: sapetnioc
severity: major
status: open
title: platform.dist() has unpredictable result under Linux
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1319] py3k: fixes for test_ctypes

[Guido van Rossum]

Guido van Rossum added the comment:

Looks good to me. I can check it in if Thomas is okay with that (or if
he remains silent long enough :-).

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1322] platform.dist() has unpredictable result under Linux

[Guido van Rossum]

Guido van Rossum added the comment:

Do you have a patch? That would help tremendously.

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1317] smtplib.SMTP docs

[Guido van Rossum]

Changes by Guido van Rossum:


--
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

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

[issue1319] py3k: fixes for test_ctypes

[Thomas Heller]

Thomas Heller added the comment:

Guido van Rossum schrieb:

> Looks good to me. I can check it in if Thomas is okay with that (or if
> he remains silent long enough :-).

Looks good to me too.  Please check it in if you have time ;-)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

[Guido van Rossum]

Guido van Rossum added the comment:

Let's not get overexcited. I agree that it makes sense for fileinput,
but I disagree about *StringIO; its close() isn't needed to free
resources (since it doesn't use up a scarce resource like a file
descriptor).

Can you whip up a patch for fileinput?  Please include unit tests and
documentation.

--
nosy: +gvanrossum
priority:  -> low
versions:  -Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1319] py3k: fixes for test_ctypes

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 58639.
You're welcome, Thomas.
And Thanks, Amaury!  Keep them coming...!

--
assignee: theller -> gvanrossum
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1303] adapt str8 constructor to bytes constructor

[Guido van Rossum]

Guido van Rossum added the comment:

Georg, can you check this in even with test_str failing?

And who is working on that?  If I don't get a name I'll tackle it myself.

--
assignee: gvanrossum -> georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1303] adapt str8 constructor to bytes constructor

[Georg Brandl]

Georg Brandl added the comment:

Okay, committed in r58640.

Gregory wrote this in test_bytes:
# I've started porting some of those into buffer_tests.py, we should port
# the rest that make sense (the code can be cleaned up to use modern
# unittest methods at the same time).

--
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1302] Fixes for profile/cprofile

[Guido van Rossum]

Guido van Rossum added the comment:

I like Chris's patch better, but he should use (sizeof(lower)-1) instead
of 8, and he should use the TOLOWER macro from bytes_methods.h.

Please submit a new one and I'll check it in!

--
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1290] xml.dom.minidom not able to handle utf-8 data

[Facundo Batista]

Facundo Batista added the comment:

CharacterData.__repr__ was constructing a string in response that keeped
having a non-ascii character.

Fixed in rev 58641.

--
resolution: works for me -> fixed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1319] py3k: fixes for test_ctypes

[Thomas Heller]

Thomas Heller added the comment:

Looking again, I found a bug in the patch.

In the function _get_args(), the local variable 'name' was
changed from 'char *' to 'PyObject *'.  In line 2995, it is
passed to PyErr_Format with a '%s' format code:

if (name)
PyErr_Format(PyExc_TypeError,
==>  "required argument '%s' missing", name);

A unittest but no fix for the bug for this issue is
attached (can I submit patches via mail?)

Added file: http://bugs.python.org/file8602/test_prototypes.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: test_prototypes.py
===
--- test_prototypes.py  (revision 58625)
+++ test_prototypes.py  (working copy)
@@ -48,6 +48,24 @@
 func.restype = c_long
 func.argtypes = None
 
+def test_paramflags(self):
+# function returns c_void_p result,
+# and has a required parameter named 'input'
+prototype = CFUNCTYPE(c_void_p, c_void_p)
+func = prototype(("_testfunc_p_p", testdll),
+ ((1, "input"),))
+
+try:
+func()
+except TypeError as details:
+self.failUnlessEqual(str(details), "required argument 'input' 
missing")
+else:
+self.fail("TypeError not raised")
+
+self.failUnlessEqual(func(None), None)
+self.failUnlessEqual(func(input=None), None)
+
+
 def test_int_pointer_arg(self):
 func = testdll._testfunc_p_p
 func.restype = c_long
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1077] itertools missing, causes interactive help to break

[Georg Brandl]

Changes by Georg Brandl:


--
status: open -> pending

__
Tracker <[EMAIL PROTECTED]>

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

[issue1753371] Open always create new tab or new browser

[Georg Brandl]

Changes by Georg Brandl:


--
status: pending -> closed

_
Tracker <[EMAIL PROTECTED]>

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

[issue1077] itertools missing, causes interactive help to break

[Georg Brandl]

Changes by Georg Brandl:


--
status: pending -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1319] py3k: fixes for test_ctypes

[Thomas Heller]

Thomas Heller added the comment:

Here's the bugfix - is it correct?

Added file: http://bugs.python.org/file8603/_ctypes.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Modules/_ctypes/_ctypes.c
===
--- Modules/_ctypes/_ctypes.c   (revision 58639)
+++ Modules/_ctypes/_ctypes.c   (working copy)
@@ -2992,7 +2992,7 @@
/* we can't currently emit a better error message */
if (name)
PyErr_Format(PyExc_TypeError,
-"required argument '%s' missing", name);
+"required argument '%S' missing", name);
else
PyErr_Format(PyExc_TypeError,
 "not enough arguments");
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1319] py3k: fixes for test_ctypes

[Guido van Rossum]

Guido van Rossum added the comment:

Looks good. Can you check it in?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1252] IDLE - patch Delegator to support callables

[Kurt B. Kaiser]

Kurt B. Kaiser added the comment:

Despite your explanation, I don't understand what is being
accomplished here.  Delegates are not intended to be callable.
They have methods, e.g. insert, which are callable, and the
insert call is propagated down the chain by calls like
(from ColorDelegator):

def insert(self, index, chars, tags=None):
index = self.index(index)
self.delegate.insert(index, chars, tags)
self.notify_range(index, index + "+%dc" % len(chars))

IMHO it's an incorrect usage of the Delegator mixin to
affect the callable nature of the class to which it's being added.

Also, this __call__ method, if actually used, propagates to the
end of the Delegator chain and calls the function at the end,
(assuming it is a function).  Or it will skip non-callable
Delegators and stop at the first callable one.

I doubt this is what was intended, and people trying to understand the code 
will be further confused, it seems to me.

Try adding delegator.txt (below) to your Delegator.py and running the
module!

I think this patch increases the complexity and obscurity of the
Delegator/Percolator/WidgetRedirector code, rather than improving
it.  Apparently you want to sometimes call a chain of methods (as
in current usage) and sometimes call a chain of functions. The
semantic overload, which was bad enough already, is too great.

If Squeezer and ShellLogger require this change, then I'd
suggest changing them to match current Percolator usage, instead.
Currently I don't see a Delegator being used in Squeezer.  Could
you be more specific about why the change is needed for those
two extensions?

Added file: http://bugs.python.org/file8604/delegator.txt

__
Tracker <[EMAIL PROTECTED]>

__class Hooker(Delegator):

def __init__(self):
Delegator.__init__(self)


class Interceptor(Delegator):

def __init__(self):
Delegator.__init__(self)

def fcn():
print "Fcn at base"

if __name__ == "__main__":
bottom = Hooker()
bottom.setdelegate(fcn)
middle = Hooker()
middle.setdelegate(bottom)
top = Interceptor()
top.setdelegate(middle)
print "top.delegate: ", top.delegate
print "calling top(): ",
top()
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1319] py3k: fixes for test_ctypes

[Thomas Heller]

Thomas Heller added the comment:

Committed as rev 58642.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1258] Removal of basestring type

[Guido van Rossum]

Guido van Rossum added the comment:

2007/10/15, Christian Heimes <[EMAIL PROTECTED]>:
>
> Christian Heimes added the comment:
>
> Guido van Rossum wrote:
> > BTW we need a 2to3 fixer for this.  Should be trivial -- just replace
> > *all* occurrences of basestring with str.
>
> I believe you that it's trivial for *you* but I've never dealt with the
> fixers or the grammar. Fortunately for me I was able to copy the fixer
> for standarderror. It toke just some minor tweaks :)
>
> Let's see if the mail interface can handle attachments.

It did. :-) I renamed it to fix_basestring and submitted it.  See:

Committed revision 58644.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1292] libffi needs an update to support mips64, arm and armeabi on linux

[Matthias Klose]

Matthias Klose added the comment:

committed the following patch to the trunk (lets the buildds test the
ctypes extension)

Added file: http://bugs.python.org/file8605/arm.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: configure.in
===
--- configure.in	(revision 58643)
+++ configure.in	(working copy)
@@ -1748,12 +1748,16 @@
 [AC_MSG_RESULT(no)])
 
 # Check for use of the system libffi library
+AC_CHECK_HEADER(ffi.h)
 AC_MSG_CHECKING(for --with-system-ffi)
 AC_ARG_WITH(system_ffi,
 AC_HELP_STRING(--with-system-ffi, build _ctypes module using an installed ffi library))
 
-if test -z "$with_system_ffi"
-then with_system_ffi="no"
+if test -z "$with_system_ffi" && test "$ac_cv_header_ffi_h" = yes; then
+	case "$ac_sys_system/`uname -m`" in
+	Linux/arm*)  with_system_ffi="yes";;
+	*) with_system_ffi="no"
+	esac
 fi
 AC_MSG_RESULT($with_system_ffi)
 
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1022] use bytes for code objects

[Guido van Rossum]

Guido van Rossum added the comment:

We won't be doing it this way.

--
resolution: remind -> rejected
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1004] MultiMethods with type annotations in 3000

[Guido van Rossum]

Guido van Rossum added the comment:

Phillip, do you have any interest left in moving PEP 3124 forward?

--
assignee: gvanrossum -> pje
nosy: +pje

__
Tracker <[EMAIL PROTECTED]>

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

[issue1004] MultiMethods with type annotations in 3000

[Phillip J. Eby]

Phillip J. Eby added the comment:

Interested, yes.  Have time for at the moment, no.  :(  Seems unlikely
I'll have time before 2008Q1 at this point.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1004] MultiMethods with type annotations in 3000

[Guido van Rossum]

Guido van Rossum added the comment:

OK, that's fine.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1287] os.environ.pop doesn't work

[Georg Brandl]

Georg Brandl added the comment:

Fixed in r58651 for 2.6.

--
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue1323] py3k: file.truncate() changes the file position

[Amaury Forgeot d'Arc]

New submission from Amaury Forgeot d'Arc:

This patch corrects a problem in test_file.py on Windows:
f.truncate() seeks to the truncation point, but does not empty the
buffers. In the test, f.tell() returns -1...

Now we flush the file before, and seek to the initial position after.
The same trick was present in 2.5, in fileobject.c::file_truncate. The
same comments apply as well.

Reviewers needed! Flushing may change the behaviour, but seems more
correct to me (and closer to python2.5). Should we add specific tests
for this?

Also, change the test to be sure to close the file before trying to
remove it (it seems that in a finally: block, the exception still
references all the local variables in the traceback). Otherwise the
previous problem is hidden by a "file locked" error in the finally block.

--
components: Windows
files: truncate.diff
messages: 56732
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: file.truncate() changes the file position
versions: Python 3.0
Added file: http://bugs.python.org/file8606/truncate.diff

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1323] py3k: file.truncate() changes the file position

[Martin v. Löwis]

Changes by Martin v. Löwis:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1311] os.path.exists(os.devnull) regression on windows

[Martin v. Löwis]

Martin v. Löwis added the comment:

The purpose of Py_GetFileAttributesEx* is to wrap GetFileAttributesEx,
on systems where it doesn't exist (Windows 95 in particular). If it
doesn't exist, it is emulated; if it exists, it is directly called.

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1311] os.path.exists(os.devnull) regression on windows

[Martin v. Löwis]

Martin v. Löwis added the comment:

As Facundo found out, the behavior of os.path.exists is fairly
irrelevant here, as that functions is trivial. What really matters is
whether os.stat succeeds for NUL. Can those users for whom it succeeds
please report what Windows versions they are using, and what precisely
the stat result for NUL is (and perhaps also for CON, PRN, etc)?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1311] os.path.exists(os.devnull) regression on windows

[Martin v. Löwis]

Martin v. Löwis added the comment:

Please disregard Cygwin Python for this discussion. It (probably) uses
the stat implementation from cygwin1.dll, which may work differently
from Cygwin release to Cygwin release.

__
Tracker <[EMAIL PROTECTED]>

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