Chris Barker via Python-Dev writes:
> But "I wrote some code in Python to produce these statistics" --
> does that need a citation?
That depends on what you mean by "statistics" and whether (as one
should) one makes the code available. If the code is published or
"available on request", defini
Jacqueline Kazil writes:
> *As a user, I am writing an academic paper and I need to cite Python. *
I don't understand the meaning of "need" and "Python". To understand
your code, one likely needs the Language Reference and surely the
Library Reference, and probably documentation of the APIs and
Jacqueline Kazil writes:
> I thought I could take two to three concrete formats and user test
> there and report on how community members who would be using the
> citation feel.
+1
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
Barry Warsaw writes:
> I like the idea of an “internals” C API documentation, separate
> from the public API.
FWIW, this worked well for XEmacs ("came for flamewars, stayed for the
internals manual").
Much of the stuff we inherited from GNU only got documented when there
was massive bugginess
Greg Ewing writes:
> (BTW, how do you provide a citation for "common knowledge"?-)
Aumann, Robert J. [1976], "Agreeing to Disagree." Annals of
Statistics 4, pp. 1236-1239
is what I usually use. :-)
___
Python-Dev mailing list
Python-Dev@python.org
h
Terry Reedy writes:
> When this behavior of set/getattr was discussed a decade or so ago,
> Guido said not to disable it, but I believe he said it should not
> be considered a language feature. There are other situations where
> CPython is 'looser' than the spec.
I'm pretty sure that all of
Chris Barker - NOAA Federal via Python-Dev writes:
> Well, yes, that particular example is pretty clear. But as a rule,
> there are a LOT of errors that can be pretty mysterious to newbies.
Isn't that the very definition of "newbie"? That's half a joke, but I
really don't think that programmer
Chris Barker - NOAA Federal writes:
> > > But as a rule,
> > > there are a LOT of errors that can be pretty mysterious to newbies.
> >
> > Isn't that the very definition of "newbie"? That's half a joke, but I
> > really don't think that programmers new to Python should be the
> > standard.
Jeroen Demeyer writes:
> I would like to propose to the new steering council to review PEP 580.
> Is there already a process for that?
I hope we can start with "same as it ever was." Looking at the list,
it's not like anything needs to change immediately. Guido, Barry,
Nick, and Brett have a
Steven D'Aprano writes:
> But even if representative, this survey only tells us what version
> people are using, now how they invoke it. We can't conclude that the
> command "python" means Python 3 for these users. We simply don't know
> one way or another (and I personally wouldn't want to
Barry Warsaw writes:
> On Feb 21, 2019, at 10:34, Raymond Hettinger
> wrote:
> >
> > I think that anything that raises the cost of filing a bug report
> > will work to our detriment. Ideally, we want the barriers to
> > reporting to be as low as possible.
A template is probably counterpro
Steve Dower writes:
> I'm sympathetic to wanting to have tasks for the PyCon sprints, but at
> the same time it feels exclusionary to "save" them from people who want
> to volunteer at other times.
It's already possible to do this sub rosa. Just get a mentor to
"claim" the issue, and have a
Karthikeyan writes:
> I would also recommend waiting for a core dev or someone to provide some
> feedback or confirmation on even an easy issue's fix
FWIW, I don't think waiting on core devs is a very good idea, because
we just don't have enough free core dev time, and I don't think we (or
any
Raymond Hettinger writes:
> We're trying to keep performant the ones that people actually use.
> For the Mac, I think there are only four that matter:
>
> 1) The one we distribute on the python.org
> website at
> https://www.python.org/ftp/python/3.8.0/python-3.8.0a2-macosx10.9.pkg
>
Barry Warsaw writes:
>`/usr/bin/env python` is great for development and terrible for deployment.
Developers of `six` and `2to3`, you mean?
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
Victor Stinner writes:
> I just fixed the mojibake issue in Python 3.8 by disabling C locale
> coercion and UTF-8 Mode by default. I'm not sure if nor how Python 3.7
> should be fixed in a minor 3.7.x release.
That sounds like a potential regression. Those two features were
added *and turned
A proponent writes:
> We have submitted PEP 570 for consideration to the steering
> council:
I would like to ask *future* proponents to please include the title
explicitly in the first mention. (This is not a criticism of the
previous post. How could he know I would write this?)
In this case
Executive summary:
"There should be a tool" (sorry, I'm not volunteering any time soon)
that could be added to $VCS diff (say, "git coverage-diff" or "git
diff --coverage").
Chris Withers writes:
> It's an interesting point; I personally don't see much value in coverage
> of less than 100%, i
Chris Withers writes:
> On 01/05/2019 17:09, Stephen J. Turnbull wrote:
> > Executive summary:
> >
> > "There should be a tool" (sorry, I'm not volunteering any time soon)
> > that could be added to $VCS diff (say, "git coverage-diff" or &q
Terry Reedy writes:
> I agree that complete 100.000% test coverage is a nice ideal, but
> sometimes the last percent can take hours to accomplish, if it is
> indeed sensibly possible.
100% test coverage is an ideal. Reports *claiming* 100% coverage,
however, are of practical benefit. The poi
Stripping the list of addressees, since I'm pretty sure all the
people who will *make* the decision read Python-Dev regularly, except
perhaps Carol.
Paul Moore writes:
> Thanks for all of these. I appreciate the time you took locating them
> for me. But I do have to say that I still can't reall
Chris Barker - NOAA Federal writes:
> Frankly, multiple long meandering threads in s single mailing list
> are not s very good archive either.
True, but I have no idea how to address that administratively, except
to have a *very* strong moderator.
> Ideally, the PEP is updated with a summary
Christian Heimes writes:
> It's all open source. It's up to the Python community to adopt
> packages and provide them on PyPI.
>
> Python core will not maintain and distribute the packages. I'll
> merely provide a repository with packages to help kick-starting the
> process.
This looks to
Neil Schemenauer writes:
> Here is an alternative, straw man, proposal. Split the CPython repo
> into two parts:
>
> - core Python: minimal possible stdlib
> - everything else
I take issue with the characterization of "straw man," it's a
practical idea that turns out to be not so e
Barry Warsaw writes:
> On Jun 6, 2019, at 09:15, David Mertz wrote:
> >
> > The old URL is definitely a lot friendlier, even apart from the length.
>
> Unfortunately, the old URLs aren’t really permanent.
True. That could be addressed in theory, but it would be fragile (ie,
vulnerable to
Oleg Broytman writes:
> On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com wrote:
> > Why don't we check the architecture using js and provide the
> > appropriate version?
>
>Because the downloading computer is not necessary the installation
> target.
Sure, but (a) it'
Jonathan Goble writes:
> As for me, I'll continue to lurk and learn as I continue my sophomore
> year as a college student majoring in computer science, with hopes of
> becoming more active in contributing to Python as I gain more
> experience and skills.
Evidently you have ambition to acquir
Steven D'Aprano writes:
> The hashability requirement for sets is, in a sense, an implementation
> detail. It might be a requirement for sets in Python the language,
> but its not a requirement for abstract "sets of values".
>
> In this case, they need to be multisets, since
>
> {'a':
Guido van Rossum writes:
> And in part because we will have specific guidelines (to be nailed
> down more precisely in the dev guide) about how to ensure that an
> issue is newcomer friendly. I don't have the thread handy but it's
> something about having a clear (to newcomers, not just to cor
Steven D'Aprano writes:
> Under what circumstances would you expect two unordered collections of
> values:
>
> {1, 2, 3, 1, 1, 1}
> {1, 2, 3, 2, 2, 2}
>
> to compare equal?
As you've pointed out yourself, I believe, here we are not interested
in generic unordered collections. W
Greg Ewing writes:
> Also it's kind of weird that just looking at data on the
> disk can change something about it.
The "something about it" *did* change. The world is a dynamic entity,
it does change. What you think is weird is that the metadata change
is recorded.
Note: you can "fix" direc
Guido van Rossum writes:
> This I also agree with. We should not assume readers know any
> particular other language,
Most of my students have Python as their first language, and my
university mandates using it in introductory courses as of this year.
I agree that there are two audiences: thos
Jim J. Jewett writes:
> I *hope* this was a typo! If
>
> case Point(x=a, y=b):
>
> assigns to a and b (instead of x and y, as in a normal call), then
> that is ... going to be very easy for me to forget, and to miss
> even when I'm aware of it.
I don't argue with your main point as
Ned Batchelder writes:
> I feel like we are missing a key element of Riccardo's point:
> "without editorial guidance." Changes are being made without
> first having an agreement about what the tutorial should be.
That's really unfortunate. But there also ought to be an editorial
activity, s
Jim J. Jewett writes:
> What advantage can there be in re-using syntax to mean something
> opposite to what it normally does?
In math, it allows us to write "solve c = f(x) for x". That doesn't
mean "bind c to the value f(x)", it means exactly the opposite. No
problem here, I suppose. So
Glenn Linderman writes:
> Mathematics never came up with separate symbols for equality and
> assignment.
Mathematics doesn't need them, until we come to an age where we do
mathematics on algorithms. It's perfectly possible to do algebra
interpreting "let x = 3" as an equation of the form "f(x)
> My suggestion: create the developers by creating group(s) of
> mentors
Do you know about
https://mail.python.org/mailman3/lists/core-mentorship.python.org/
and if you do, why isn't that what you suggest?
___
Python-Dev mailing list -- python-dev@
Paul Sokolovsky writes:
> Well, I'd call that "cowboy attitude in programming language
> design" ;-).
That was uncalled for, especially since you're selling an idea without
an implementation yourself.
> We'd certainly make it blend well with the rest of Python.
But how long will that take?
Paul Sokolovsky writes:
> Also to clarify, [cowboy attitude] referred to difference in
> approaches in response to particular issue(s) raised. One thing is
> to say "it's hard to implement it better with the limited VM
> infrastructure and resources we have" (that of course leads to
> further
Paul Sokolovsky writes:
> Sorry, but there may be a suggestion of tactics of sneaking somebody's
> "pet feature" past the attention of core developers by employing
> sycophant techniques.
I've had enough of your random aspersions. They make it impossible
for me to continue reading your posts.
Alfred Perlstein writes:
> PR 22981 is a minor update to doctest to allow it to safely consume
> modules which contain objects that cause inspect.unwrap to throw.
>
> I believe the review comments in the PR have been addressed at this
> point for ~20 days. The patch is relatively small, r
Paul Bryan via Python-Dev writes:
> Should this be considered a bug in the Enum implementation?
Probably not. The underlying implementation of Enums is integers, and
False and True *are* the integers 0 and 1 for most purposes. And it
propagates further. Same example:
>>> class Foo(enum.Enum)
Chris Angelico writes:
> Can you explain what would be improved by having a formalized
> standard?
The Language Reference together with the Library Reference *already*
constitute a formalized standard. They are at least as precise as
most W3C or IETF standards.
What you and Dan seem to be ref
Paul Sokolovsky writes:
> Hello,
>
> On Sat, 13 Feb 2021 23:10:59 +0900
> "Stephen J. Turnbull" wrote:
>
> > Chris Angelico writes:
> >
> > > Can you explain what would be improved by having a formalized
> > > standard?
>
Mike Miller writes:
> Sounds like automating until it is "just a push of a button,"
> should be a goal. According to Victor there has been progress, but
> always room for more.
When XEmacs was releasing betas regularly, everything from tagging the
local authoritative repo to pushing to the pub
Mike Miller writes:
> "sys-admin" is a bit of an overstatement in my phrasing. The core
> is that you need to understand how a PATH works and be able to run
> pip and cd into folders and perhaps run rm/del, etc. Basic
> command-line skills?
That's what I would mean by basic sys-admin skills
Steven D'Aprano writes:
> On Fri, Feb 26, 2021 at 11:41:56AM +0900, Stephen J. Turnbull wrote:
> > That's what I would mean by basic sys-admin skills. And *surprise!*
> > my students don't have them, and don't need them ... until they start
> > using
Executive summary: This thread is about a "seven blind men and an
elephant" problem.
Jim J. Jewett writes:
> I think his point is that most of his students (economics or
> business, rather than comp sci) will never need to use Perl or C or
> Java. Python is friendly enough to be useful, but t
Jim J. Jewett writes:
> > which file am I actually running?
> > which interpreter am I actually running?
> > how do I tell the computer to use a different interpreter?
>
> If you need to care about any of these, then the environment is
> fighting you -- and the application probably stinks.
Paul Moore writes:
> The one thing that *is* substantially worse for Python, is the
> circumlocutions needed in the documentation to say how to run Python.
> But that's 100% down to us not being willing to say "just type the
> command python". And the reason for *that* is mostly historical,
>
Antoine Pitrou writes:
> On Sun, 04 Apr 2021 00:34:18 -
> "Brandt Bucher" wrote:
> > Can you please stop putting scare quotes
> I'm not a native English speaker, but I don't understand how
> putting quotes around a reasonably polite expression devalues
> anyone's work.
"Scare quotes"
Mark Shannon writes:
> Calling something a "reference" implementation suggests that it is
> something that people can refer to, that is near perfectly correct and
> fills in the gaps in the specification.
Shoe fits, doesn't it? Both Guido and Brandt to my recall have
specifically considered
Matthias Klose writes:
> Looking at the failing CI tests triggered by these builds, yes I
> see that 32bit archs have the ABI change.
I'm not sure precisely what you mean by that, but if you mean that CI
has caught the bug, then
> So maybe it's worth to re-introduce these RC builds,
seems to
Matthias Klose writes:
> No, you can't see that with CPython's CI alone. The Debian and
> Ubuntu build machines trigger CI tests per architecture for around
> 3000 packages depending on python3.9, using the just built
> python3.9, and without rebuilding these packages. That's where I
> see
Paul Moore writes:
> It *is* merged and publicly released - it's in the latest 3.10
> alpha.
Merged, yes, but in my terminology alphas, betas, and rcs aren't
"public releases", they're merely "accessible to the public". (I'm
happy to adopt your terminology when you're in the conversation, I'm
Greg Ewing writes:
> On 7/04/21 5:22 am, Brandt Bucher wrote:
> > we might consider updating those templates if the term "Reference
> > Implementation" implies a higher standard than "we've put in the
> > work to make this happen, and you can try it out here"
>
> Maybe "prototype implementat
Paul Moore writes:
> I'm OK with these terms (although I don't actually think you *will*
> get sufficient consensus on them to make them unambiguous)
> once the implementation is merged into the CPython source, I think
> it should simply be referred to as "the implementation" and
> qualifi
Hugh Fisher writes:
> In any Python 3.6 or later, type
>
> >>> x : float = 1
> >>> isinstance(x, float)
> >>> type(x)
[snip]
> As someone who has programmed in FORTRAN, Pascal, C/C++,
> Java, and Go this is not at all what I consider reasonable.
>From the point of view of typi
Hugh Fisher writes:
> There are a lot of programmers like me. Those languages I listed
> are widely used, and therefore we assume that if a Python language
> construct looks like something we've used before, it will work in
> the same way.
That's not very persuasive. When in London, England,
Denis,
There's a standard way of interesting the Python community in new
syntax (and C++, while not Python, is new syntax in spades to this
community ;-).
You take a hunk of the standard library (in this case it would have to
be an accelerator written in C since you want to compare C++ vs. C) or
Luciano Ramalho writes:
> A HUGE insight I learned studying Go is that Protocols should be
> defined near the code that CONSUMES it, and not near the code that
> PROVIDES it. That's exactly the opposite of how we use ABCs, or
> Java folks use interfaces (most of the time).
I don't see how tha
Chris Angelico writes:
> On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote:
> > Duck typing usually falls squarely into the EAFP category.
>
> Isn't it orthogonal?
Not really. If you ask 'thing' to 'thing[0]', you don't find out
whether it is a list or a dict (or any number of other thin
Paul Moore writes:
> What you're missing, I think, is that we're talking about
> typing.Protocol - see here:
> https://docs.python.org/3/library/typing.html#typing.Protocol
I understand that we're talking about typing. What I don't understand
is how any general facility provided in a standard
Abdur-Rahmaan Janhangeer writes:
> No i mean fake path in the sense of a fork
> of CPython with issues for learning purposes
*Creating* plausible issues is hard work, I assure you as a university
professor. Coming up with "exercises" that are not makework requires
expertise in both the domain
Mark Shannon writes:
> On 13/05/2021 5:32 am, Terry Reedy wrote:
> > The claim that starts the Motivation section, "Python is widely
> > acknowledged as slow.", has multiple problems.
> How would you rephrase it, bearing in mind that needs to be short?
We can make CPython run significan
Abdur-Rahmaan Janhangeer writes:
> That's why i guess what i am proposing might seem simple
I'm saying that we already have the simple version, spelled
git clone; git checkout main~5000
then
git log -U0 main~5000..main | grep -v '^[-+ ]'
which provides very nice hints for the diligen
Steve Holden writes:
> On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano
> wrote:
>
> > Steve
> > (one of the other ones)
> >
>
> We are all other Steves!
+1
There were five Steves (and one Stephanie) in my 6th grade class (of
27). "Steve, move that " became an idiom
-- Other Ste
Oscar Benjamin writes:
> The break even point where both implementations take equal time is
> around about 5% density. What that means is that for a 1000 x 1000
> matrix with 10% of elements nonzero it is faster to ask flint to
> construct an enormous dense matrix and perform a huge number of
Christopher Barker writes:
> I find this whole conversation confusing -- does anyone really think a
> substantial performance boost to cPython is not a "good thing"?
> [PyPy, Numba, Cython] are why Python is very useful today -- but
> none of them make the case that making cPython run faster
Irit Katriel via Python-Dev writes:
> Andrei is suggesting to look at each enum value as the set of "bits set to
> 1" in this value, and then apply a set-thoery term to the problem.
> [...] Anyway, I don't know whether this kind of terminology is
> widely accessible.
I think the everyday mea
Christopher Barker writes:
> A byte is not a character
While I am -0.5 on bchr for many of the reasons already cited in the
thread (and would be -1 if the methods names proposed for the feature
were a bit more aesthetic), I don't think this argument is valid.
Bytes that could otherwise be arbitr
Antoine Pitrou writes:
> In what context is `bchr()` useful?
As a builtin, not my problem, I'm not the proponent. As a facility
with *some* spelling, it's convenient in contexts where chr() is, but
much less so (eg, coding ROT13 ;-). I know I've used this translation
in mail hacking, but I don
In re: Requests for Censorship :-(
Luciano Ramalho writes:
> Instead of going silently, I wanted to call on the adult supervision
> to do something about the adult.
I'm sympathetic, because I value your participation in this list. But
I'm also sympathetic to the moderators, because usually th
Terry Reedy writes:
> We could add (perhaps at the end of the first paragraph) something like
> "(Since the 2.x stdlib is frozen, all 2.x-specific guidelines were
> removed in Sept 2021.)" Anyone interested could then check git log for
> the last commit before then.
How about including th
Christopher Barker writes:
> PR here:
Thanks for your prompt efforts! The notes toward a "near future"
agenda are above and beyond.
> Interesting some of the cruft in there e.g. still referring to "new style
> classes" :-)
I think that should also come out "now", but that's a +1 to the ide
Marc-Andre Lemburg writes:
> On 26.08.2021 06:07, Christopher Barker wrote:
> > But now a question -- the current text reads:
> >
> > "Code in the core Python distribution should always use UTF-8"
> > "The following policy is prescribed for the standard library
> > ... In addition, string
Ethan Furman writes:
> `int.from_bytes` methods, and is an appropriate name for the target
> domain (where bytes are treated as characters).
The relevant domains treat bytes as bytes. It's frequently useful
(and dare I say "Pythonic"?) for *programmers* to take advantage of
the mnemonic of tre
Eric V. Smith writes:
> >> But this does not:
> >>
> >> f'{1 +
> >> 2}'
> >
> > The later is an error with or without the 'f' prefix and I think that
> > this should continue to be the case.
> >
> The thought is that anything that's within braces {} and is a valid
> expression should b
Guido van Rossum writes:
> I don't know about the line breaks, but in recent weeks I've found myself
> more than once having to remind myself that inside interpolations, you must
> use the other type of quote.
My earlier remarks were specifically directed to line breaks.
I see the point, but
jack.jan...@cwi.nl writes:
> I’m getting increasingly worried about the future of Python,
You mean about the fact that Python has a plethora (rapidly growing!)
of powerful, efficient extension packages and you want to use them
all (perhaps recursively)? :-) I really don't think this bodes ill
Nick Coghlan writes:
> For compatibility with file encoding declarations, I believe this
> needs to be relaxed to starting with '#!python' in the source file
> encoding, rather than strictly b'#!python' (which will only be the
> case for ASCII compatible encodings).
In any PEP-263-compatible
Jesse Noller writes:
> I guess someone need to write a proof of concept exploit for you
> and release it into the wild.
This is a bit ridiculous. This stuff looks easy enough that surely
Christian's post informed any malicious body who didn't already know
how to do it. If the exploit matters,
Ethan Furman writes:
> Again:
Repeating yourself doesn't help make the case. It does, however,
encourage me to reply.
> Definition of ENUMERATE
> 1 : to ascertain the number of : count
> 2 : to specify one after another : list
You say you need the value as an integer; when you evaluate, yo
Ethan Furman writes:
> sjt wrote:
> > Note that in both counting and listing the object of the
> > operation is not an element. It is a set, and set membership is
> > the most important aspect of the elements for that purpose.
>
> No, it isn't. It may be in some cases.
I'm referring o
Ethan Furman writes:
> Ah, okay. Although, going with the first definition -- "ascertain
> the number of" -- I still maintain that the number is equally
> important, otherwise it could be a simple set.
Of course "number" is central to counting -- but you can count a set
of objects that have n
Antoine Pitrou writes:
> On Tue, 26 Feb 2013 08:03:40 -0800
> Ethan Furman wrote:
> > I'm beginning to see why enums as a class has not yet been added
> > to Python. We don't want to complicate the language with too
> > many choices, yet there is no One Obvious Enum to fit the wide
> > vari
Greg Ewing writes:
> Stephen J. Turnbull wrote:
> > Worse for me, most of the applications I have, I'd like the enumerator
> > identifiers to be both string-valued and int-valued: the int used to
> > index into Python sequences, and the string used in formatting SQL.
Stefan Krah writes:
> Why would [the PSF list] help to resolve such an issue (if it is an
> issue at all!)
Precisely.
If there *is* a compliance problem, there's nothing to be done before
talking to the lawyers. Although license *choice* is primarily a
political issue, *compliance* is technic
Mark Lawrence writes:
> People already use the bug tracker as an excuse not to contribute,
> wouldn't this requirement make the situation worse?
A failure to sign the CLA is already a decision not to contribute to
the distribution, no matter how noisy they are on the tracker and
list. I think
Terry Reedy writes:
> > or a proposal for a change that is given within a bug tracker message?
>
> I view a proposal for a change as just an idea. Such usually get
> re-written by whoever creates an actual patch.
Precisely how U.S. law would view it, implying no copyright issue.
If this re
Steven D'Aprano writes:
> Pardon my ignorance, but how does a CLA protect us in the event of an IP
> violation?
By licensing the content to the PSF, the contributor implicitly claims
that he has the right to do so (I think the AFL even has an explicit
provenance clause). This protects the PSF
Paul Moore writes:
> I have no figures one way or the other on that. You may well be
> right. Are we aiming at "all Windows users" here?
We need to be careful about this. ISTM that IDLE is aiming at the
subset of users on any platform who for some reason need/want a simple
development environ
Todd Rovito writes:
> All this is good information and makes me feel even better about
> waiting a few months to get these four issues and possibly more IDLE
> issues fixed before the next release.
+1 for more issues fixed in the next release! :-)
_
Skip Montanaro writes:
> It sounds like many people at PyCon are still 2.x users.
I suspect we're all still 2.x users at some level.
But the question is not "where are the users?" It's "where do the
development resources come from?" Pretty clearly, the python-dev
crowd has voted with their ke
Barry Warsaw writes:
> I would like to make a definitive statement as to 2.7's EOL because
> I think that will spur more people to work on porting.
I have to agree with the people who say that it's not a major spur.
Internal support for existing Python 2.7 installations is by now quite
a bit le
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > Mark Lawrence writes:
> >
> > > People already use the bug tracker as an excuse not to
> > > contribute, wouldn't this requirement make the situation
> > > worse?
>
Ben Finney writes:
> As it currently stands, the Contributor Agreement grants special
> legal privilege in the work (the power to unilaterally re-license
> the work) to the PSF.
"I hate to disagree, Sir, but that turns out to be incorrect."[0]
First, it's not the Contributor Agreement, it's t
Skip Montanaro writes:
> > Would it make sense to think about adding this in the scope of
> > the argument clinic work, or is it too unrelated? This seems like
> > a commonly needed thing for large parts of the stdlib (where the
> > C accelerator overrides Python code).
>
> Or maybe separat
Devin Jeanpierre writes:
> why does 'abc'.encode('unicode_escape') return bytes?
Duck-typing: encode always turns unicode into bytes.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
R. David Murray writes:
> You transform *into* the encoding, and untransform *out* of the
> encoding. Do you have an example where that would be ambiguous?
In the bytes-to-bytes case, any pair of character encodings (eg, UTF-8
and ISO-8859-15) would do. Or how about in text, ReST to HTML?
BA
401 - 500 of 1553 matches
Mail list logo
