ticking point, as usual depending on use
>cases.
It might even be a feature-win if a standard on-demand import mechanism could
be added on top of importlib so all these projects wouldn't have to roll their
own.
-Barry
___
Python-Dev mailing l
eltas, and to use them in these APIs, then at the very least, the PEP
needs a stronger rationale for why this is. But I think ultimately, it would
be better for Python to improve the resolution, and API support for datetimes
and timestamps.
In any case, thanks for your work in this (and so ma
ys its time to change the
default? etc.
Also, if Python 2.7 is being changed to add this feature, why can't Python 3.2
also be changed? (And if there's a good reason for not doing it there, that
should be added to the PEP.)
Cheers,
-Barry
nything
>to do with us.
Then I think all the PEP needs to say is that it is explicitly up to the
distros to determine if, when, where, and how they transition. I.e. take it
off of python-dev's plate.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
e Epoch, which is a well-defined start time at least
on *nix systems. So clearly those types of functions could return datetimes.
I'm fairly certain that between those types of functions and timedeltas you
could have most of the bases covered.
-Barry
sig
r resolution is necessary.
My primary concern with the PEP is adding to users confusion when they have to
handle (at least) 5 different types[*] that represent time in Python.
Cheers,
-Barry
[*] int, float, Decimal, datetime, timedelta; are there others?
signature.asc
Description
shouldn't be confused with bypassing them.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
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;naive") UTC time, even
> if that's the only timezone that comes with Python.
+1
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
inks just so the mechanism is clear.
Works for me.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
7;t any
time soon).
If you mark the PEP as Final, we still have the option of updating the PEP
some time later to reflect new recommendations. It might be worth a quick
sentence to that effect in the PEP.
As I say though, this is a very minor quibble, so just DTRT. +1 and thanks
for your gr
.
Please however, do test the Python 2.6 branch thoroughly, both with and
without randomization. We'll be coordinating release candidates between all
affected branches fairly soon.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
>2012/2/21 Antoine Pitrou :
>>
>> Hello,
>>
>> Shouldn't it be enabled by default in 3.3?
Yes.
>Should you be able to disable it?
No, but you should be able to provide a seed.
-Barry
___
On Feb 21, 2012, at 09:58 PM, Xavier Morel wrote:
>On 2012-02-21, at 21:24 , Brett Cannon wrote:
>> On Tue, Feb 21, 2012 at 15:05, Barry Warsaw wrote:
>>
>>> On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
>>>
>>>> 2012/2/21 Antoine Pitrou :
s and the like?
>
>As for "false sense", can't we document this and chalk up hubristic
>behavior to "consenting adults"?
+1
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.
and be done with it. I don't think
there's anything useful to expose to Python or communicated between Python
executables when truly random hash data is used.
Thus, unless there are objections, I consider the current state of the Python
2.6 branch to be finished wrt issue 13703.
Ch
he maintainer, as long as the module is consistent. Also, modules which
provide a format-ish API should accept both styles, such as what logging
currently does. (It's nice that logging also accepts PEP 292 $-strings too,
don't forget about those. :)
-Barry
_
ng timestamp from os.stat is a float, and you can't compare floats
> and non-naive datetimes. How is this an issue?
Exactly.
>Perhaps someone else can propose something even better,
If we really feel like we need to make a change to support higher resolution
timestamps, this com
it's doing more harm than good."
While it may be true for *some* problem domains, such as WSGI apps, it is not
true in general, IMO. I use this future import all the time in both libraries
and applications and it's almost always help
a separate module
that could be used in earlier Python versions.
-Barry
___
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
it.
>>
>>
>+1 from me for the same reasons.
Just to be clear, I'm solidly +1 on anything we can do to increase the pace of
Python 3 migration.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
FOP agrees you can mark them Final, since I think
they almost are, effectively.
Marking them Final doesn't mean they can't be updated if you find some issues
with them later. You and the BDFOP might decide to defer Final acceptance
until the bugs in the implementations are fixed
m a single code base for the last couple of
years that that will still be necessary .
Cheers,
-Barry
___
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
her better solution out there. I
don't do a lot of web development these days so I can't say.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
her extremely annoying things, like str(bytes) returning the repr
>of a bytestring on Python 3. That's almost as irritating as the absence
>of u'' literals, but we have to evaluate one thing at a time.
Yeah, that one has bitten me many times, and for me it *is* more irritating
at's the only way IMO that the PEP can be judged on its own
merits.
(I'll concede for the sake of argument that 2to3 is unacceptable. I also
think it's unnecessary though.)
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.o
f our mutual :) benefit to stop arguing.
I still urge the PEP author to clean up the PEP and specifically address the
issues brought up in this thread. That will be useful for the historical
record.
-Barry
___
Python-Dev mailing list
Python-Dev@python.
opers feel
>better about themselves. :-)
One of them's a winner in my book, but I'll let you guess which one. OTOH,
the time machine can bring you back to the future again.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
elping developers understand exactly how to do
this effectively, among the many great options that exist today. Only in the
most extreme cases or the most inertially challenged projects should we say
"wait for Python 3.3".
Cheers,
-Barry
___
Python-
and spread the word.
We really need to stop saying that porting to Python 3 is hard, or should be
delayed. It's not in the vast majority of cases. Yes, there are warts, and
we should continue to improve Python 3 so it gets easier, but by no means i
r(bytes) thing is a pain, but it too can be worked around, and
is such a minor wart that it should not delay your porting efforts.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
are still fighting with their API decisions for Python 3."""
>
>While it may be as such for you, I think it is incorrect for the rest.
>Moreover, it is harmful for the python 3 adoption, to put such documents
>on python.org.
+∞
-Barry
ild up the dependency stack so that
when the large frameworks are ready, your library which they may depend on,
will have a long and stable history on Python 3.
-Barry
___
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/False debacle in 2.2.1?
Cheers,
-Barry
___
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 for Python 3."""
>
>Could you just remove the statement completely?
If I read correctly, Nick is undertaking a rewrite of PEP 414, which should
help a lot.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
ly, it was the same strategy as any
porting process, but the key was breaking these up into reviewable chunks that
could be applied while still keeping the code base Python 2 only.
I really do think that to the extent that you can do that kind of thing, you
may end up with essentially Py
On Mar 01, 2012, at 09:42 AM, Guido van Rossum wrote:
>I noticed there were some complaints about unnecessarily offensive
>language in PEP 414. Have those passages been edited to everyone's
>satisfaction?
Not yet, but I believe Nick volunteered to do a re
yway.
The PEP could simply say that for some domains, the ability to port code from
Python 2 to Python 3 would be enhanced by the reintroduction of the u-prefix.
It could even explain why WSGI applications in particular would benefit from
this. That would be enough to justify Guido's acceptanc
n web frameworks so I
defer to those who are. It certainly can't be applied to the entire universe
of Unicode-aware Python 2 applications.
>Accordingly, I'd like to ask folks not to stress too much about the
>precise wording until I get a chance to update it
Just like today we're trying to provide a smoother path for LTS->LTS upgrades
where 10.04 had only Python 2.6 but 12.04 has only Python 2.7. We have a
semi-official Lucid PPA providing Python 2.7, though afaict very few people
have actually used
es. For these, there's no need to define "native strings", nor do
they require language constructs above what's already available.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
've been hoping for. Maybe it will work the other way around
>too: People like 3.3, target it first and port back later to reach more
>users. It's all about encouraging people to try the nectar of Python 3 – once
>they're caught it's sticky sweetness[1]… ;)
Indeed!
ons/2.7/lib/python2.7/plat-darwin',
'/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
'/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
'/Library/Frameworks/Pyt
On 3 Mar 2012, at 21:57, Ned Deily wrote:
> In article <5a0e2490-a743-4729-a752-d94524ea9...@barrys-emacs.org>,
> Barry Scott wrote:
>> On my Mac OS X 10.7.3 System I have lots of python kits installed for
>> developing extensions.
>>
>> I'll just not
be a more descriptive alias for
`str`. If you can do it in a readable way within the context of that section
I think it's worth mentioning this.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@pyth
Just to follow up. With Robin's help over in wxPython land I have
given Robin a patch to wxPython to fix the site-packages issue.
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
On Mar 12, 2012, at 07:33 PM, Brett Cannon wrote:
>It came up at the sprints about how to choose new PEP numbers. It was
>agreed that the newest, *lowest* number should be used (e.g. 418) and not
>the next highest number (e.g. 3156). I have already updated PEP 1 to
>reflect this.
On Mar 17, 2012, at 11:34 PM, barry.warsaw wrote:
>http://hg.python.org/cpython/rev/6144a0748a95
>changeset: 75809:6144a0748a95
>branch: 2.6
>parent: 75806:bd9e1a02e3e3
>user:Barry Warsaw
>date:Sat Mar 17 18:34:05 2012 -0400
>summary:
>
ges, so I think this would
be useful information for either the devguide or PEP 101, or both. I updated
the latter right at the --tag step.
Thanks,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
be avoided by merging all changesets from
>X.Y to X.Y+1, not null-merging, unless I misunderstand something.
Except in this case, there's probably not much useful in the 2.6.8 changes
that are appropriate for 2.7.
-Barry
___
Python-Dev mailing li
er list is
doing any content filtering. We could always enable that if we wanted to get
strict about it.
In this case, this isn't html email, it's likely this bug:
https://bugs.launchpad.net/mailman/+bug/558294
Cheers,
-Barry
___
Python-Dev m
On Apr 03, 2012, at 12:44 AM, Antoine Pitrou wrote:
>I don't think Barry still uses bzr, and who ever used git to manage their
>patches against the CPython repo?
I still use bzr, but not currently for Python development. I just use the
standard hg repo. I'd like to go back t
access" API of pkg_resources.
http://peak.telecommunity.com/DevCenter/PkgResources#basic-resource-access
I'm not suggesting that we adopt all of pkg_resources, but I think the 5
functions listed there, plus resource_filename() (from the next section)
provide basic functionality I'
code's here:
><http://twistedmatrix.com/trac/browser/trunk/twisted/python/modules.py>
>
>The API is fairly simple.
>
>>>> from twisted.python.modules import getModule
>>>> e = getModule("email") # get an abstract "module" object (un-l
for the semantic content of the code. As such,
including best practices for naming context managers would both appear
out-of-place, and possibly get lost in all the whitespace noise :).
Perhaps the contextlib docs are a better place for this?
-Barry
___
Py
On Apr 16, 2012, at 07:44 PM, Antoine Pitrou wrote:
>Wouldn't it be better if Python could compile regardless of the
>presence of a hg repository?
If you want it in your $DISTRO, yes please!
-Barry
___
Python-Dev mailing list
Python-Dev
what I always use. No spaces inside the brackets for me :)
>
>If the expression gets unreadable that way, factor it out.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
9 10:32:50 2012 +0200
+++ b/pep-0008.txt Thu Apr 19 10:53:15 2012 -0400
@@ -305,7 +305,11 @@
``>=``, ``in``, ``not in``, ``is``, ``is not``), Booleans (``and``,
``or``, ``not``).
-- Use spaces around arithmetic operators:
+- If operators with different priorities are used,
tended meaning.
If I change that phrase to "Use your own judgement" does that help?
-Barry
___
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
H, it's unlikely there are, or would be, many consumers for it.
Strictly speaking, I do think you need to deprecate the APIs. I like Nick's
suggestion to make them C wrappers which just call back into Python.
-Barry
___
Python-Dev mailing li
y-to-list and don't CC me, then the copy I get will be the list
copy, which will have a List-Post header, and I'll also reply-to-list. No
dupes in sight, just like this one. SJT, FTW.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
h
ck my python.org address for messages to Python
mailing lists.
That's all I'll say on the subject in this mailing list, but I'm happy to
answer other questions off-line.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://
ing, and can
help you find packages that need resources in getting to Python 3.
At the Ubuntu Developer Summit in Oakland, California, May 7-11, 2012, we'll
also be holding some sessions on Python 3, so if you're in the area, please
come by.
http://uds.ubuntu.com/
Cheers,
-Bar
dering the positive reaction and the
>scope of the addition, does this need a PEP?
It's somewhat of a corner case, but I think a PEP couldn't hurt. The
rationale section would be useful, at least.
-Barry
___
Python-Dev mailing list
P
r bits into the stdlib?
-Barry
___
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
ing it
>actually out there in the field and getting tested.
That seems reasonable to me. The documentation should be clear as to what's
provisional and what's stable. With that, and based on your level of
confidence, I'd be in favor of getting email6 into Python 3.3.
Cheers,
-B
oon), this simply isn't going to happen for 3.3.
I concur.
-Barry
___
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
em to point to 420.
-Barry
___
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
3.3 from source, you'll also want to install liblzma-dev.
Cheers,
-Barry
___
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
of the czar role (sadly, no clever bacronym
has come to mind, and BDFOP hasn't really taken off ;).
>+* Run ``./genpepindex.py`` and ``./pep2html.py `` to ensure they
>+ are generated without errors. If either triggers errors, then the web site
>+ will not be updated to reflect the PEP changes.
On May 05, 2012, at 12:56 PM, Barry Warsaw wrote:
>before the final PEP can be approved. When an `PEP-Czar` header must be
>added to the PEP to record this delegation. The format of this header is
>the same as the `Author` header.
s/When an/A
;t care about my pdo address getting
obfuscated, and would opt for email address inclusion. I can appreciate that
others might feel differently.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
On May 06, 2012, at 03:08 PM, Nick Coghlan wrote:
>I'll see if I can figure out something - I may just put in text like
>"if you're at all unsure about what needs to be done, email the PEP
>editors anyway".
The dif
nstalls its system packages into dist-packages not
site-packages. This is a Debian delta from upstream.
http://wiki.debian.org/Python
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
e development *of* Python, not using it or developing *with* it.
>
>I would try your question on comp.lang.python/python-list.
There are lots of good resources for Debian-specific Python issues (mailing
lists, IRC, etc.). Start here:
http://wiki.debian.org
precedence that we
should be sure we want to establish.
Cheers,
-Barry
___
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
. I think sys.implementation.metadata
should be the same type.
Cheers,
-Barry
signature.asc
Description: PGP signature
___
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
64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/
+1
This would make a good fix for Python 3.3. Matthias, p
tablish a naming convention for alternative constructors implemented as
{static,class}methods. I don't like `build_class()` much. Would you be
opposed to `type.new()`?
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
table.
>> I think sys.implementation.metadata
>> should be the same type.
>
>This I wonder about. The more I think about it, the more it fits.
>I'll give it a day and if that still holds I'll work it in.
Cool.
>Thanks for the feedback, Barry!
there may be merit in not being so specific about
>the type. I'll give that some thought.
Right. See my previous follow up for what I think the PEP should say about
the semantics of the type, without being so specific about the actual type.
Cheers,
-Barry
I this new type was
also exposed in the collections module.
-Barry
___
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
to the constructor get turned
>into members.
Well, "__init__(self, **kws)", but yeah. :)
-Barry
___
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
ating or defining it.
>It's the type equivalent of constructing an instance, perhaps?
If, as Nick proposes in a different message, it actually does make better
sense to put this as a module-level function, then putting `class` in the name
makes sense. types.{new,create,build,construct}_class(
y is useful to preserve in
sys.implementation. I'm on the fence, but maybe "we're all consenting adults"
and "simplest thing that will work" should rule the day.
Using a straight up dict and underscores for non-PEP-defined values is
certainly simple,
y for sys.implementation, but I still think
attribute access is a more useful model. You can easily support both getattr
and getitem with a class instance, so I think that's the way to go.
(FWIW, immutability would also be easy to support with an instance.)
-
5. 415 should get a Replaces header that points to
409. Then PEP 415 should get a section describing how the bulk of 409 is
still valid, except for blah blah blah. (IOW, include the still valid parts
of PEP 409 by reference.)
Cheers,
-Barry
___
Python-De
czar , I'd approve it.
-Barry
___
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
At what point should we cut over docs.python.org to point to the Python 3
documentation by default? Wouldn't this be an easy bit to flip in order to
promote Python 3 more better?
Cheers,
-Barry
signature.asc
Description: PGP signature
___
Pytho
On May 18, 2012, at 11:36 AM, Benjamin Peterson wrote:
>2012/5/18 Barry Warsaw :
>> At what point should we cut over docs.python.org to point to the Python 3
>> documentation by default? Wouldn't this be an easy bit to flip in order to
>> promote Python 3 more better?
On May 20, 2012, at 04:27 PM, Raymond Hettinger wrote:
>When there is more uptake of Python 3, it would be reasonable move.
How do we measure this, and what's the milestone for enough uptake to make
the switch?
Cheers,
-Barry
signature.asc
Description: PGP s
elease of 3.3,
puts 3.4 final in February of 2014.
>>> final33 = datetime.datetime(day=25, month=8, year=2012)
>>> final34 = final33 + datetime.timedelta(days=18 * 30)
>>> final34.isoformat()
'2014-02-16T00:00:00'
Cheers,
-Barry
___
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
I've mentioned this in private to a few folks, with generally positive
feedback.
I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If
there are no objections in the next few days, I'll make it official.
Cheers,
-Barry
signature.asc
Description: PGP
> module = XXX new module here
> module.__path__ = _NamespacePath(...stuff involving 'parent' and
>'attr')
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
ion patch has been pushed to Python 2.6 in
Lucid 10.04.4 yet, which still has Python 2.6.5 (plus patches, but not that
one).
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
t side-tracked, but I'm planning on getting back
to it soon.
-Barry
___
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
On May 21, 2012, at 05:24 PM, Barry Warsaw wrote:
>I've mentioned this in private to a few folks, with generally positive
>feedback.
>
>I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If
>there are no objections in the next few days, I'll make
n development community, and the PEP looks great. I have not yet
reviewed the patches in issue 14673, but the last message on that item
indicates the patch is not yet up-to-date with the PEP description.
Please update the issue, and if possible, let's get it landed before Sunday's
alpha 4.
type.
Specifically, while I think that filtering out _names in the repr is fine for
sys.implementation, it would not be appropriate for a generalized, public
type.
OTOH, I'd have no problem just dropping that detail from sys.implementation
too. (Note of course that even with that, you can get th
ial case for _names in the repr, and
update your patch to include types.SimpleNamespace, I'd happily review it
again and support its inclusion.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
f if-statements that would probably require?
Eric's C code is easily auditable to anyone who knows the C API well enough,
and I can't imagine it wouldn't be pretty trivial to write it in Java,
RPython, or C#.
Cheers,
-Barry
___
Python-Dev mail
2301 - 2400 of 2826 matches
Mail list logo
