ncerns.
>
> OK, but that doesn't mean the information is unimportant. +1 on
> making this something of a priority. People looking for this info
> should find it in the obvious place. Some are unobvious. (How fast is
> dict.__eq__ on average?
Grig Gheorghiu wrote:
> Please let me know if you're interested.
As I said earlier: If you need some kind of post-commit
trigger on the python repository to trigger a build, just
let me know. We currently use a more-or-less plain
svn_buildbot.py to trigger our own builds.
Regards
tributed for people
> interested in this effort.
Right. You still need to find out when to rebuild, and getting triggers
from the source repositories is likely the easiest solution.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http
not have
> a free version.
Interesting. So people can do the same with the free 2003 version.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/
information is available, then distutils should
fail instead of returning incorrect information.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
lease submit a patch to sf.net/projects/python
It would be good if you could get other people that attempt to
cross-build Python to comment. A detailed howto might help to get them
started with your code.
Regards,
Martin
___
Python-Dev mailing lis
since it's a regression from 2.4
that may break many SAX applications, and perhaps also DOM applications.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
7; that comes from line 674 may be
> dereferenced by passing argument 1 to function
> 'statement_mark_dirty' at line 599.
Looks like a problem. Maybe a break is missing after line 674?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
can be sent to [EMAIL PROTECTED],
however, for reports/reviews, please use the Wiki at
http://wiki.python.org/moin/CallForTrackers
You'll notice that it also lists Trac and Malone, however,
it seems that there is no progress on importing SF data
into the
at correct? If so, would it be correct to add:
>
>unsigned short prefix_index = decomp_data[index] & 255;
>assert(prefix_index < (sizeof(decomp_prefix)/sizeof(*decomp_prefix)));
Yes, that would be correct.
Regards,
Martin
_
ntinue to direct you to the right item in the new tracker.
This can only be done when we actually make the switch, since currently
the redirector still needs to direct to SF.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Terry Reedy wrote:
> ""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Currently, we have two running tracker demos online:
>>
>> Roundup:
>> http://efod.se/python-tracker/
>>
>> Jira:
>>
ince
it then goes into
PyErr_Format(PyExc_SystemError,
"expected tuple for closure, got '%.100s'",
closure->ob_type->tp_name);
which crashes just the same.
Regards,
Martin
___
Python-Dev m
is actually helped
when I tried to get the Cygwin slave to get unstuck, and shouldn't
do harm since we currently don't run to builds on the same slave
simultaneously, but could be surprising when parallel builds
are activated some day.
Sorry for messing with your machine,
Martin
__
s out.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
#x27;t need RM permission to fix a bug.
Do you have a patch ready that restores path_importer_cache behavior,
yet preserves the property that it caches existence of a directory?
If not, I will have to produce one.
Regards,
Martin
___
Python-
Neal Norwitz wrote:
> Anthony and I talked about still having b3 on Aug 1. rc1 around Aug
> 17-18 (just before the Google sprint which Martin, Jeremy and I will
> be attending). Final around 24-29. We didn't discuss with Martin
> yet, so these dates are quite tentative.
That
ing a last-minute feature.
So do you have a patch, or are going to write one?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/p
(in a signed sense).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
OTOH, if kill() is more widely available than
> alarm(), I'll give it a try, but going by the docs, I'd say it isn't.
Indeed, alarm should be available on any POSIX system.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
h
is released
(or perhaps even before that).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e an object that supports
exc.reason_notice())
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Tony Nelson schrieb:
>> You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes
>> that share the console of the calling process.
[...]
> Martin, your advice is usually spot-on, but I don't always understand it.
> Maybe using it here is just complicated.
ng, you can also install VS Express 2005, and
use the PCbuild8 projects directory; these changes should work the
same under both versions.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
because he doesn't feel responsible if he isn't, and nobody else
will feel responsible because the patch is assigned.
As Skip explains, I have a 5-for-1-rule for people who really want
to push their patches: If you review 5 patches, I will review yours
(despite me normally ignoring patches to th
and reported the bug when you
discovered it. So thanks for reporting it.
FWIW, the bug that Thomas found was introduced by
patch #1434038, and committed as r42916.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
with a "not convertible" exception). Which of the
two conversions is selected is arbitrary; we should, of
course, continue to use the one we always used (for
"ascii", there is no difference between the two).
Regards,
Martin
_
e. where you don't get an
exception):
py> u"foo" == "sbb"
False
py> u"foo".encode("rot13") == "sbb"
True
So the strings compare as unequal, even though they compare
equal if treated as rot13. That doesn't stop Python from considering
ing patches. Interest in
receiving bug reports for systems we don't have access to is low.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
doubtful that such a change can still be made,
and if it is, that it will be "right". I'm accepting patches
regardless.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
t_tp_hash should be changed
to just truncate long ints to the range LONG_MIN..LONG_MAX
Notice that this error could have occurred already in 2.4,
on a 64-bit system where sizeof(void*) > sizeof(long) (i.e.
on Win64).
Regards,
Martin
___
Python-Dev mailin
")
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'latin-1' codec can't encode character u'\u0308' in
position 1: ordinal not in range(256)
In addition, it's also possible to find encodings (e.g. iso-2022) where
differe
>>>
>>>> This seems the most (only ?) logical solution.
>>> No; always considering Unicode and non-ASCII byte strings to be distinct
>>> is just as logical.
>
> I think you must have misread my comment:
Indeed. The misunderstanding originates fr
hould always be built with the assembler
> implementations.
But Visual Studio doesn't ship with an assembler! So how could I
build it?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
are in feature freeze now, so adding a feature
is a big no-no. You should have argued this is a bug <0.5 wink>.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
a limited case
(ascii); beyond that, Python assumes that non-ascii strings represent
uninterpreted bytes, not characters.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
x27;t be that bad.
For SSL specifically, the usage of hashing is minimal, as the actual
communication uses symmetric encryption.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
d raise an exception.
It could be out of memory, it could be that there is an
internal/programming error in the codec being used, it could be
that the codec is not found (likewise for other comparisons).
However, if the codec is working properly, and clearly determines
that the byte string has no
and I have suggested to make it even more user-friendly
by defining string-unicode-__eq__ in a sensible manner. It
is more user-friendly, because it doesn't show the inconsistency
Michael Hudson documented in
http://mail.python.org/pipermail/python-dev/2006-August/067981.html
Regards
go ahead and fix it that way.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
k it's necessary, a note could be added to the readme. Would
you like to create a patch?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
t is "release-critical" (i.e. it would be really embarrassing for
Python 2.5 if that change wasn't made), you should put it into the
appropriate section.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Tim Peters schrieb:
> It sounds fine to me, except I'm not immediately clear on which code
> needs to be changed.
My change would essentially be the code below, in instance_hash and
slot_tp_hash; I have yet to add test cases and check for documentation
changes.
Regards,
Martin
Ind
t for software as well, but not
so for free software (I assume).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
he code being in the
> binary causing a problem.
See, my own worries come from the "if". Should I risk breaking
somebody's application just because somebody else is worried about
breaking patents? You haven't indicated whether you also worry:
do you?
Regards,
Martin
___
n
> algorithm?
Perform it: do the steps that the algorithm says you should
do, or let a machine do it. IOW, run the code.
If your point is that software patents are evil: I fully
agree.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.or
be a constructor
> call?
Now, *that* question makes no sense. Why do you need special syntax
to create a temporary object?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
n that was ever released (e.g. we skipped some between 3.2 and
4.1 also).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Ralf Schmitt schrieb:
> any chance to get SimpleXMLWriter (and other modules maybe??) getting
> included into xml.etree?
Not in Python 2.5, no.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
ode
if the string is not in the system encoding).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Armin Rigo schrieb:
> This bug will keep showing up forever :-) It's unsafe against a user
> subclassing 'long' and overriding __hash__ of that subclass to return
> the object itself -- it would cause an infinite C recursion.
I see you'
ercial use (I believe
to anybody, ask the patent owner if uncertain); commercial
users need to buy a license (I would expect that transferable
licenses are also available for sale).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
Guido van Rossum schrieb:
> Me too, and that's what we'll do in py3k. But in 2.5, we're bound by
> the decisions we made in 1999-2000 about unicode. (Unless Martin has a
> convincing reason not to have a warning?)
Only the general anti-warning argument: it's not the
too complicated
to understand.
Now I looked at it, and think that the recipe is broken. It should
add an __eq__ method which is
def __eq__(self, other):
return type(self) is type(other) \
and self.EnumType is other.EnumType \
and self.__value==other.__valu
at
> least patch the stdlib's version of Elementtree to produce an output
> more in line with the w3 standard.
That is out of the question. It was agreed that ElementTree is added
to the standard library only if Fredrik Lundh gets veto rights on
all changes.
Regards,
Martin
n call via a
> new __setcall__?
Just try specifying this one day. I'm sure a dozen readers of the list
will rip apart the first specification you make as underspecified or
unimplementable (hint: what is the precise syntax for the left-hand
side? how to parse it? wha
id foo(){
X(1) += 2;
}
int bar, foobar;
int& X(int t){
if(t) return bar;
return foobar;
}
Here, which variable gets incremented depends on whether the t
argument is true; no overloading of assignment comes into play.
The trick is that C++ has functions that *return* lval
access any version". We likely drop
3.2 when IDNA stops using it, and we likely drop 4.1 when moving to 5.0.
Of course, now the infrastructure is there for keeping old versions
efficiently, so if compelling reasons are brought forward to keep an
old version, it would
w large the specification of a seemingly simple feature
will be.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ight" approach?
For the moment, the first section gets augmented by "issue a
warning if you think the user is comparing things incorrectly".
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
s to whether NotImplemented
should ever be returned in these. decimal.py believes
it does (for different types), sets.py believes it
doesn't.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d
code will run just fine on older versions of Python as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
gs)
If that happens often enough, you can write
def function(f):
return lambda *args:f(*args)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
r23251 | tim_one | 2001-09-20 09:55:22 +0200 (Do, 20 Sep 2001) | 3 lines
SF bug [#463093] File methods need doc strings.
Now they don't.
I can only guess why it may go away; my guess it will go away when
the buffer interface is removed from Python (then it
are (see range_item and range_length), but it assumes that it is
> safe to cast long to ssize_t and back.
Where does it assume that it is safe to case ssize_t -> long?
That would be a bug.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev
e that ptrdiff_t, although standard C, is not a very
> intuitive name, but ssize_t is even less clear.
In the discussion, ptrdiff_t was never brought up as an alternative
(intptr_t was; see the PEP for why it is unsuitable). ssize_t seemed
most natural to me since si
unnoticed for
years; I do worry if patches get unnoticed/unprocessed for years.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
care if bug reports get unnoticed for
>> years; I do worry if patches get unnoticed/unprocessed for years.
>
> Then a "has-patch" flag would be okay, wouldn't it, along with assigning
> a higher priority?
Sure, that would work as well.
Regards,
Martin
_
hen delegate all bug reports "distutils
doesn't work with older Python releases" to MAL. As far as I'm
concerned, this isn't a distutils feature anymore.
Regards,
Martin
(*) where "back" means 2.5.0, not 2.4.0.
___
Pyt
:-).
Ah, that's why it isn't ptrdiff_t: Tim Peters said he liked ssize_t
> I was not suggesting Py_ptrdiff_t. My suggestion was "Py_index_t",
> but I am six month late :-(.
Indeed, it is too late for such a change.
Regards,
Martin
_
tinue to parse
int?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
M.-A. Lemburg schrieb:
> I find it important to maintain distutils compatibility with
> a few Python versions back. Even if I can't volunteer to
> maintain distutils, like Martin suggested, due to lack of time,
> I don't really see the requirement to use the latest and grea
cator (which we should (*)), there isn't
any space increase on such a platform. On a 64-bit platform, the
size of an int would go up from 24 bytes to 32 bytes.
Regards,
Martin
(*) people have complained that the memory allocated for a large
number of ints isn't ever reused. They
l listed in PEP 291, 2.1 compatibility was mentioned
as a goal. Now, it doesn't seem to bother you very much
that 2.1 compatibility is gone.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
James Y Knight schrieb:
> But it's the short int that you probably really want to make size
> efficient.
Only if you have many of them. And if you do, you have the problem
of the special-cased allocator: when the many ints go away, Python
will hold onto their memory forever.
Rega
Greg Ewing schrieb:
> Martin v. Löwis wrote:
>> We had this discussion before; if you use ob_size==0 to indicate
>> that it's an int, this space isn't needed in a long int.
>
> What about int subclasses?
It's what Guido proposes.
It would still leave two type
the special-case allocator also
comes from the fact that it doesn't ever have to release
memory. Just try changing it to see what I mean.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
e base type hierarchy to
find out its not inherited from int).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[EMAIL PROTECTED] schrieb:
> Guido> I worry that dropping the special allocator will be too slow.
>
> Greg> Surely there's some compromise that would allow recently-used ints
> Greg> to be kept around, but reclaimed if memory becomes low?
>
> Marti
e currently have; dispatching on
> exact type (which we discourage anyway) would be the only case. Would
> that be so bad?
I thought it was the ultimate goal of PEP 237 to unify int and long,
in all respects.
I'll do some benchmarking.
Regards,
Martin
s test case is extremely focused on measuring int
allocation (I just noticed I should have omitted the for loop in
the second case, though).
Regards,
Martin
import time
s = time.time()
i = 0
while i < 1000:
i+=1
print "Test 1",time.time()-s
s = time.time()
i = 0
for i in rang
n
Test 3 1.8s 2.1s 15%
Test 4 3.6s 3.8s 5%
test 5 7.5s 7.5s 0
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
pth] is B)
Space requirement is linear with the depth of the class
(but I think tp_mro could be used, if the formula is
changed to (C.bases[C.depth-B.depth] is B))
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
So overall, I would expect that a single type would improve performance,
not decrease it.
As you say, any change is likely not noticeable in performance, though,
either way.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
EMAIL PROTECTED](%ecx), %eax
cmpl %eax, 4(%edx) ; %edx is the object
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
can now see the status of the 2.5 branch
at
http://www.python.org/dev/buildbot/2.5/
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
I'd like to fix the two build failures that the Windows buildbots
show for the 2.5 trunk. I'm not quite sure what the OpenSSL failure
is, yet, but the sqlite error should be fixable with the patch
below. Ok to work on this?
Martin
Index: Tools/buildbot/ex
test_uuid1 and test_uuid4 fail consistently on Windows; apparently,
the generated universally-unique identifiers aren't even unique within
a set of 1000 identifiers.
Can somebody please fix that? If not, should we remove the uuid module
as being immature?
Regards,
M
Georg Brandl schrieb:
>> Can somebody please fix that? If not, should we remove the uuid module
>> as being immature?
>
> Patch #1541863 supposedly solves this.
Ah, good. I think it should go in.
Regards,
Martin
___
Python-Dev maili
?
You misunderstand indeed: the chunk reads
-for u in [uuid.uuid1() for i in range(1000)]:
+for u in [uuid.uuid4() for i in range(1000)]:
so it currently calls uuid1, and will call uuid4 when patched.
test_uuid4 should have never failed, except that it uses uuid1
as the unique
to just not worry about
it.
There are many other problems with Win64 still, e.g. the test suite
doesn't pass.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
ant
to drop IA-64 binaries in 2.6, due to lack of interest).
If you think it means "has known bugs", then this applies to
all Python releases on all target systems, ever (just look
at the open bugs list).
Regards,
Martin
___
Python-Dev mailin
(if indeed it is)
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess),
and was released for Win64 throughout Python 2.4. ActiveState has
been releasing an AMD64 package for some time now.
Regards,
Martin
___
Python-Dev mailing list
o python
> 2.5, I'm happy to do it.
As you can see from my comment, I think it really is a bug in the
application. Without reviewing it again, I think disallowing empty
package names might be the right thing; this can only be done in 2.6,
though.
Regards,
Martin
_
new feature: it makes applications
possible which aren't possible today, and the documentation does not
ever suggest that these applications should have been possible. In fact,
it is common knowledge that this currently isn't supported.
Regards,
Martin
__
gt; But it *is* a desirable, albeit new, feature, so I'm surprised that you
> don't appear to perceive it as such for a downstream release.
Because 2.5.1 shouldn't include any new features. If it is a new feature
(which it is), it should go into 2.6.
Regards,
Martin
nd on sys.path; changing that might break them.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ding the domain of an argument to an
existing function is a new feature.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
havior follows the specification, or a
specification change so that it correctly describes the behavior.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ke
__file__ becomes a unicode string on Windows, and remains a byte
string encoded with the file system encoding elsewhere. That's also
a change in behavior.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
2001 - 2100 of 5755 matches
Mail list logo
