t import native_str
foo = "this is a Unicode string in both Python 2.x and 3.x"
bar = native_str("this is an 7-bit string in Python 2.x"
" and a Unicode string in 3.x")
baz = b"this is an 8-bit string in Python 2.x and a bytes object in 3
nd
> 3.2 was a U-turn.
Unfortunately (?), there is a near-contract-like agreement with Fredrik
Lundh that any significant changes to ElementTree in the standard
library have to be agreed by him. So whatever change you plan: make sure
Fredrik gives his explicit support.
Regards,
Martin
__
:: 3.3
>
> I'm not sure I understand. Why would you make a copy of an immutable
> object?
It can convert a unicode subtype object into a an exact unicode
object.
I'd rename it to _PyUnicode_AsExactUnicode, and undocument it.
Regards,
Martin
_
Am 09.12.2011 10:09, schrieb Xavier Morel:
> On 2011-12-09, at 09:41 , Martin v. Löwis wrote:
>>> a) The stdlib documentation should help users to choose the right
>>> tool right from the start. Instead of using the totally
>>> misleading wording that it uses now, it
hanges that
Stefan proposed (which are actually different from yours).
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
Am 09.12.2011 10:12, schrieb Nick Coghlan:
> On Fri, Dec 9, 2011 at 6:44 PM, "Martin v. Löwis" wrote:
>> Am 09.12.2011 01:35, schrieb Antoine Pitrou:
>>> On Fri, 09 Dec 2011 00:16:02 +0100
>>> victor.stinner wrote:
>>>>
>>>>
x27;s deprecate the NiCad batteries and try to guide users toward the
> Li-Ion ones.
If you are proposing to deprecate minidom: -1
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
> I can't recall anyone working on any substantial improvements during the
> last six years or so, and the reason for that seems obvious to me.
What do you think is the reason? It's not at all obvious to me.
Regards,
Martin
___
Python-
it's a bit obscure why the function exists.
I'm skeptical about this modification part. If you make a copy, it's
not clear at all that the new characters that you put in will fit
in range with the width of the unicode string. Even decreasing the
ordinal of a character may be incor
. In most cases, the line numbers
in the 2to3 result are exactly the same as in the original, and if
not, the quoted source in the traceback will give you enough context
to find the source line of the problem.
Regards,
Martin
___
Python-Dev mail
les (comparing time stamps
between the build/ area and the original source).
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
ou need to consider
original-preserving saves first.
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
ctually necessary. With the project ported to 2.6,
you could then make use of the 3k warnings to learn what issues you
would face when porting to 3k.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
e
of kind values: many places will either work incorrectly, or have
an assertion in debug mode already if an unexpected kind is
encountered. I don't mind adding such checks to more places, but I
also don't see a need to explicitly care about this specific class
of bugs where people would ha
tly corrupting data.
In debug mode, or release mode? -1 on release mode.
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
identical-source approach (more dramatically so
if you also want to support 2.5 or 2.4).
> Anyway, if you're supporting both 2 and 3, a common code base offers
> many attractions, so if it can be done, it will.
And 2to3 is a good approach to maintaining a common code base.
Rega
e world" is a frequent
> occurence.
Unfortunately, these issues never get reported. I worked on porting
zope.interface, and it never took 30 minutes for me, not even remotely.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http
Am 12.12.2011 10:04, schrieb Stefan Behnel:
> "Martin v. Löwis", 11.12.2011 23:39:
>>> I can't recall anyone working on any substantial improvements during the
>>> last six years or so, and the reason for that seems obvious to me.
>>
>> What do you
In many of these cases, it turned out that they were
trying to run some software that uses PyXML, and that they tried
installing PyXML to satisfy the prerequisite. So while they may not
be software developers, they are indirectly "users" of PyXML.
Regards,
Martin
__
e back to python-dev for review to determine whether it's
worth to support such systems.
Alternatively, you can just make your own fork of Python, which
you may or may not publish.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://
Am 14.12.2011 20:41, schrieb Stefan Behnel:
> "Martin v. Löwis", 14.12.2011 19:14:
>> Am 12.12.2011 10:04, schrieb Stefan Behnel:
>>> "Martin v. Löwis", 11.12.2011 23:39:
>>>>> I can't recall anyone working on any substantial improvements
&
ng files and folders is the
> only thing that python needs to be compiled (i'm talking about 2.7) then
> it's possible to fail-check it by just trying to open the file.
That's not true. It also looks at the file modification time.
Regards,
Martin
_
> Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum
What's the rationale for that change? It's a valid kind value, after
all, and the C convention is that an enumeration lists all valid values
(else there wouldn't be a need for an enumeration in the first place)
Am 18.12.2011 20:45, schrieb Victor Stinner:
> On 18/12/2011 20:34, "Martin v. Löwis" wrote:
>>>Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum
>>
>> What's the rationale for that change? It's a valid kind value, after
>> all, and the C
Am 18.12.2011 21:16, schrieb Victor Stinner:
> On 18/12/2011 21:04, "Martin v. Löwis" wrote:
>>> PyUnicode_KIND() only returns PyUnicode_1BYTE_KIND, PyUnicode_2BYTE_KIND
>>> or PyUnicode_4BYTE_KIND. Outside unicodeobject.c, you are not supposed
>>> to see Py
ement? Have something expand
to either the object file name, or nothing.
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/pyth
rate over all methods (taking base
classes into account).
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
here,
since these methods then still have attributes assigned to self.
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
s, so the overhead would be negligible.
I'm not so much concerned about overhead, but about correctness/
effectiveness of the heuristics. For a class with dynamic attributes,
you may well come up with a very large key set. With source analysis,
you wouldn't attempt to grow the keyset beyond what li
> If I'm wrong and its easy to implement then please do.
Ok, so I take it that you are not interested in the idea. No problem.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
gt; ElementTree.
Of course, for minidom, Mark's current implementation should already
save quite a lot of memory, since all elements and text nodes have the
same attributes.
Still, it would be good to see how Mark's implementation deals wi
On 01/02/2012 10:02 PM, julien tayon wrote:
@francis
Like indent ?
http://www.linuxmanpages.com/man1/indent.1.php
Thank you, I wasn't aware of this one !
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
t share the concern that there is a risk of
somebody being confused when adding a second statement to a braceless
block. An actual risk is stuff like
if (cond)
MACRO(argument);
when MACRO expands to multiple statements. However, we should
accept that this is a bug in MACRO (which should
need to
switch to a different system, or provide a patch to access the
platform's native random number generator.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
dy had braces in place much more
> readable.
Is it really *much* more readable? I have no difficulties reading either
(although I had preferred a space after the if; this worries me
more than the double if line).
Regards,
Martin
___
Python-Dev mailing lis
on to run /dev/MAKEDEV (or similar), or
to mount devfs into a chroot environment; else many programs run in the
chroot are likely going to fail (e.g. if /dev/tty is missing).
See, for example,
http://tldp.org/HOWTO/Chroot-BIND-HOWTO-2.html
bind apparently requires /dev/null and /dev/random.
R
er such a change would be accepted, in particular as
Microsoft might fix the bug in the compiler until the final release
of Windows 8.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
> It seems that svn.python.org certificate expired today (09/01/2012).
I have now replaced the certificate. The current one will expire on
Chistmas 2013.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
y to the nt module to make it compile).
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
oject. Not sure whether this is triggered by defining WINAPI_FAMILY=2,
or any other compiler setting.
I'd really love to use WINAPI_FAMILY=2, as compiler errors are much
easier to fix than verifier errors.
Regards,
Martin
___
Python-Dev mailing l
then.
Of course, pointing the OP to a more specific focused forum (which is
not always cython-users) is also kind.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
only one bit set
pathological. However, this can be overcome by factoring the magnitude
of the number into the hash as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
nder the limitation).
A valid counterexample would have to come from a real application, or
at least from a scenario that is plausible for a real application.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
be
better IMO.
As for completely automating the build: please take notice of
Tools/buildbot/build.bat. It also fully automates the build, also
doesn't require that the VS environment is already activated,
and has the additional advantage of not requiring Python to be
o different
from 2008.
Regards,
Martin
P.S. Please shorten your messages. They contain too much text for me to
grasp.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
ence of
probed indices is the same for any MASK value. It will be a different
sequence, yes, but they will still collide on each and every slot.
This is the very nature of open addressing. If it *wouldn't* try all
indices in the probe sequence, it may not be possible t
oject,
I'd like to ask for a volunteer who will lead this project. You
get the honor to commit the changes, and you will be in charge if
something breaks, hopefully finding out solutions in a timely manner
(not necessarily implementing the solutions yourself).
Any volunteers?
Regards,
Martin
change actually arrives at end users, many months will pass.
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
ce, cache either the dict-hash or the public
hash, depending on which one gets computed first, and recompute
the other one every time it's needed.
As you can see, 1 vs. 2/3 is a classical time-space-tradeoff.
What do you think?
Regards,
Martin
__
do you agree that we switch? Do you volunteer to drive the change?
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
ilable on WinRT, you have to use
CreateSemaphoreExW (which is new in Windows Vista). No traces of
the CE API can be seen in the restrictions, and the separation
is done in a different manner (WINAPI_FAMILY==2).
Regards,
Martin
___
Python-Dev mailing
Am 17.01.2012 22:26, schrieb Antoine Pitrou:
> On Tue, 17 Jan 2012 21:59:28 +0100
> "Martin v. Löwis" wrote:
>> I'd like to propose a different approach to seeding the string hashes:
>> only do so for dictionaries involving only strings, and leave the
>> tp
Am 18.01.2012 07:06, schrieb Gregory P. Smith:
>
> On Tue, Jan 17, 2012 at 12:52 PM, "Martin v. Löwis" <mailto:mar...@v.loewis.de>> wrote:
>
> > I plan to commit my fix to Python 3.3 if it is accepted. Then write a
> > simplified vers
will also break
them. My concern is about applications that assume that hash(s) is
stable across runs, and we do have reports that it will break
applications.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
Am 18.01.2012 17:01, schrieb PJ Eby:
> On Tue, Jan 17, 2012 at 7:58 PM, "Martin v. Löwis" <mailto:mar...@v.loewis.de>> wrote:
>
> Am 17.01.2012 22:26, schrieb Antoine Pitrou:
> > Only 2 bits are used in ob_sstate, meaning 30 are left. These 3
Am 18.01.2012 13:30, schrieb Barry Warsaw:
> On Jan 18, 2012, at 08:19 AM, Martin v. Löwis wrote:
>
>> My concern is not about breaking doctests: this proposal will also break
>> them. My concern is about applications that assume that hash(s) is
>> stable across runs, and
ple) would need to adjust our vacation plans with the release
schedule, or else step down (unless you would release the "normal"
feature releases as source-only releases).
FWIW, it might well be that I can't be available for the 3.3 final
release (I haven't finalized my va
cure worse than the disease.
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
t it
as a patch to the tracker, as it will need to be reviewed (possibly
with requests for further changes).
If not, it would be good if you could give a list of things that need to
be done before you consider submission to Python.
Also, please submit a contrib form if you haven't done so.
R
witch, these should actually replace the current ones, rather
than being additions.
> So, I guess my question is, is that work useful?
Perhaps not, given that several other copies of that to draw from may
exist. OTOH, I haven't heard anybody reporting these specific changes.
In any case
t already was a patch. What do I need to do to make it a patch?
I missed your announcement of issue13903; all is fine here.
> Where do I find it?
http://www.python.org/psf/contrib/contrib-form-python/
Thanks,
Martin
___
Python-Dev mailin
27;t affect any
of the lookup procedures. If you trust that the dictionary semantics on
its own isn't changed (which I believe is the case, except for key
order), none of the dict applications will change.
Regards,
Martin
___
Python-Dev mailing
, A−AFFFD,
B−BFFFD, C−CFFFD, D−DFFFD, E−EFFFD
D.2 Ranges of characters disallowed initially
1. 0300−036F, 1DC0−1DFF, 20D0−20FF, FE20−FE2F
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
> Python is supposed to work on many platforms ans so support a lot of
> compilers, not only compilers supporting non-ASCII identifiers.
And your point is?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
and
for C99 so that they didn't implement it; they recommended to use C++
or C#, anyway. Now C2011 has been published.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
der OS X releases.
So when you build a bug fix release, just build it with the same tool
chain as the previous bug fix release, and all is fine.
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
C is fully supported; this is now resolved). It is
actually feasible to change Python so that it compiles with a C++
compiler and still continues to compile as C also, with just
a few ifdefs.
This is, of course, off-topic wrt. the original question: even
C++11 compilers often don't support n
ges in
a direction that demeans some XML library in favor of some other.
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
over
ownership, with all its consequences (long-term commitment, willingness
to defend difficult decisions even if you are constantly being insulted
for that decision, and so on).
*Not* having an owner just means that it will be as unmaintained in
the future as it appears to be now.
Regards,
Martin
__
uot; encoding, the risk for confusion and untestable
code is too high (just consider the ongoing saga of the Turkish dotless
i (ı)).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
gt; with other modules, fixing bugs, tests, documentation and so on?
If we really can't find somebody dedicated to that code base enough,
we should consider removing it from the standard library.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ok at the patch, you'll notice that the only change is to
make the links hard links.
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
Am 12.02.2012 17:04, schrieb Antoine Pitrou:
> Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit :
>>> Why hard links? Symlinks are much more introspectable. When looking at
>>> a hard link I have no easy way to know it's the same as whatever
> IMO a symlink is far and away the better choice in this situation.
Please wait with that judgment until you see the rationale of the PEP
author.
Thanks,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
current practice for bug fix releases, and
b) of limited use for existing installations which won't use the API.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
the mark with the actual issue number (or add it to the References).
For the patch, it seems that one open issue is OSX support, although
I'm unsure what exactly the issue is.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
;aware" (rather than "naive") UTC time, even
if that's the only timezone that comes with Python.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
ialized APIs.
Not supporting ns timestamps is something I can readily agree to.
However, contributors won't agree to that, and will insist that these
be added (and keep writing patches to do so) until it does get added.
Some of them are core cont
, so
three of them make a nanosecond. As the quartz may not be entirely
accurate (and also as the CPU frequency may change) you have to measure
the clock rate against an external time source, but Linux has
implemented algorithms for that. On my system, dmesg shows
[2.236894] Refined TS
Am 15.02.2012 21:06, schrieb Antoine Pitrou:
> On Wed, 15 Feb 2012 20:56:26 +0100
> "Martin v. Löwis" wrote:
>>
>> With the quartz in Victor's machine, a single clock takes 0.3ns, so
>> three of them make a nanosecond. As the quartz may not be entirely
>
> Maybe an alternative PEP could be written that supports the filesystem
> copying use case only, using some specialized ns APIs? I really think
> that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
I'm -1 on that, because it will make people write complicated code.
R
ot; to me promises something that it likely can't
deliver. OTOH, I still think that the promise isn't actually asked
for in practice (not even when overwriting bytecode files)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
ree package would pronounce that it is ok to make
this change, I'd have no objection at all. Lacking a maintainer, I feel
responsible for any bad consequences of that change, which makes me feel
uneasy about it.
Regards,
Martin
___
Python-Dev ma
her has happened.
It would also good if you would declare "I will maintain the etree package".
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
may also add them for 2.6 and earlier, but we are not going to make
a release in that direction).
It may be that the PEP becomes irrelevant before it is widely accepted:
if the sole remaining Python 2 version is 2.7, users may just as well
refer to
e a file is what people might need.
One way of providing this might be a "u" mode for open, which
updates an existing file on close (unlike "a", which appends,
and unlike "w", which truncates first).
Regards,
Martin
___
Am 16.02.2012 10:51, schrieb Victor Stinner:
> 2012/2/16 "Martin v. Löwis" :
>>> Maybe an alternative PEP could be written that supports the filesystem
>>> copying use case only, using some specialized ns APIs? I really think
>>> that all you need is
emains split,
> otherwise the table is combined.
Hi Mark,
Answering on-list is fine, but please do add such answers to the PEP
when requested.
I have such a question also: why does it provide storage for the value
slot in the keys array, where this sl
Am 13.02.2012 13:46, schrieb Mark Shannon:
> Revised PEP for new dictionary implementation, PEP 412?
> is attached.
Committed as PEP 412.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
to be as long as
> the number of keys, rather than rounding them up to a large-enough
> power-of-two? (On average, this should save half the slots.)
Good idea. However, how do you track per-dict how large the table is?
Regards,
Martin
___
Python-De
ne whether it needs to grow the array, it needs to find out
how large the array is, no? So: how do you do that?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
As the PEP czar for PEP 394, I have reviewed it and am happy to say that
I can accept it. I suppose that Nick will keep track of actually
implementing it in Python 2.7.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http
MO (where Get returns "new"
references). This would give PyErr_GetExcInfo/PyErr_SetExcInfo.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
go for yoctoseconds (ys).
There is an absolute boundary, though: it seems there is no point in
going shorter than the Planck time (5.4 * 10**-44).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
the intentions to take the blame if
> something breaks.
Would you mind adding yourself to
http://docs.python.org/devguide/experts.html
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
So what do you think about Jim's proposal to make the values indexed
not by hash value, but by an index that is stored in the shared keys?
Since the load will be < 2/3, this should save 1/3 of the value storage
(typically more than that, if you initialize the values array alw
disable it?
>
> PYTHONHASHSEED=0 should disable it. Do we also need a command-line
> option?
On the contrary. PYTHONHASHSEED should go in 3.3, as should any
facility to disable or otherwise fix the seed.
Regards,
martin
___
Python-Dev mailing
hing must be consistent with equality; everything
else should be an implementation detail.
With that attitude, supporting explicit seeds is counter-productive.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
t,
I tried isinstance(o, Element), which failed badly.
Feel free to dismiss this application as irrelevant, but I do wish
that somebody was in charge of ET who was taking backwards
compatibility as serious as Fredrik Lundh.
Regards,
Martin
___
Python-Dev ma
x27;t fight it, but it seems to me
> that accepting unicode in the binascii and base64 APIs is a bad idea.
No - it's only the choice of error that is a bad idea.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
4201 - 4300 of 5764 matches
Mail list logo
