So when it is time to guess [at the character encoding of a file],
a source of good guesses is an important battery to include.
The barrier for entry to the standard library is higher than mere
usefulness.
Agreed. But most programs will need it, and people will either
include (the same)
Steven D'Aprano wrote:
I think that heuristics to guess the encoding have their role to play,
if the caller understands the risks.
Ben Finney wrote:
In my opinion, content-type guessing heuristics certainly don't belong
in the standard library.
It would be great if there were never any
(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
Serhiy Storchaka wrote:
If the transform() method will be added, I prefer to have only
one transformation method and specify a direction by the
transformation name (bzip2/unbzip2).
Me too. Until I consider special cases
(Tue Oct 29 12:37:52 CET 2013) Victor Stinner wrote:
For consistency, you cannot keep traces when tracing is disabled.
The free() must be enabled to remove allocated memory blocks, or
next malloc() may get the same address which would raise an assertion
error (you cannot have two memory
(On June 19, 2013) Barry Warsaw wrote about porting mailman from
flufl.enum to the stdlib.enum:
Switching from call syntax to getitem syntax for looking up an
enum member by name, e.g.
-delivery_mode = DeliveryMode(data['delivery_mode'])
+delivery_mode =
Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:
The use of multiple names in this field *must not* be used for
bundling distributions together. It is intended for use when
projects are forked and merged over time ...
(1) Then how *should* the
Summary:
*Every* Parameter attribute is optional, even name. (Think of
builtins, even if they aren't automatically supported yet.)
So go ahead and define some others that are sometimes useful.
Instead of defining a BoundArguments class, just return a copy
of the Signature,
In http://mail.python.org/pipermail/python-dev/2012-April/119134.html
Benjamin Peterson wrote:
I see PEP 418 gives time.clock_info() two boolean fields named
is_monotonic and is_adjusted. I think the is_ is unnecessary and
a bit ugly, and they could just be renamed monotonic and adjusted.
I
In http://mail.python.org/pipermail/python-dev/2012-March/118024.html
Steven D'Aprano wrote:
What makes this steady, given that it can be adjusted
and it can go backwards?
It is best-effort for steady, but putting best in the name would
be an attractive nuisance.
Is steady() merely a
In http://mail.python.org/pipermail/python-dev/2012-March/117570.html
Steven D'Aprano posted:
Need is awfully strong. I don't believe it is the responsibility
of the standard library to be judge and reviewer of third party
packages that it doesn't control.
It is, however, user-friendly to
In http://mail.python.org/pipermail/python-dev/2012-March/117762.html
Georg Brandl posted:
+ If available, a monotonic clock is used. By default, if *strict* is
False,
+ the function falls back to another clock if the monotonic clock failed
or is
+ not available. If *strict* is
In
view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html
van.lindberg at gmail.com posted:
1) The layout for the python root directory for all platforms should be
as follows:
stdlib = {base/userbase}/lib/python{py_version_short}
platstdlib =
In http://mail.python.org/pipermail/python-dev/2012-March/117617.html
van.lindberg at gmail.com posted:
As noted earlier in the thread, I also change my proposal to maintain
the existing differences between system installs and user installs.
[Wanted lower case, which should be irrelevant;
http://mail.python.org/pipermail/python-dev/2012-March/117396.html
Stefan Behnel posted:
I found a problem in the current yield from implementation ...
[paraphrasing]
g1 yields from g2
g2 yields from g1
XXX python follows the existing delegation without checking re-entrancy
http://mail.python.org/pipermail/python-dev/2012-March/117395.html
Brett Cannon posted:
[in reply to Mark Shannon's suggestion of adding a builtins parameter
to match locals and globals]
It's a mess right now to try to grab the __import__()
implementation and this would actually help clarify
In http://mail.python.org/pipermail/python-dev/2012-March/117348.html
Georg Brandl ge...@python.org posted:
Python 3.3 includes a range of improvements of the 3.x series, as well as
easier
porting between 2.x and 3.x. Major new features in the 3.3 release series
are:
As much as it is
In http://mail.python.org/pipermail/python-dev/2012-February/117113.html
Victor Stinner posted:
An immutable mapping can be implemented using frozendict::
class immutabledict(frozendict):
def __new__(cls, *args, **kw):
# ensure that all values are immutable
In http://mail.python.org/pipermail/python-dev/2012-February/117070.html
Vinay Sajip wrote:
It's moot, but as I see it: the purpose of PEP 414 is to facilitate a
single codebase across 2.x and 3.x. However, it only does this if your
3.x interest is 3.3+
For many people -- particularly those
In http://mail.python.org/pipermail/python-dev/2012-February/116953.html
Terry J. Reedy wrote:
I presume that most 2.6 code has problems other than u'' when
attempting to run under 3.x.
Why?
If you're talking about generic code that has seen minimal changes
since 2.0, sure. But I think
In http://mail.python.org/pipermail/python-dev/2012-February/116955.html
Victor Stinner proposed:
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
It is also possible to use ctypes and
PEP author Mark Shannon wrote
(in
http://mail.python.org/pipermail/python-dev/attachments/20120208/05be469a/attachment.txt):
... allows ... (the ``__dict__`` attribute of an object) to share
keys with other attribute dictionaries of instances of the same class.
Is the same class a
In http://mail.python.org/pipermail/python-dev/2012-February/116073.html
Nick Coghlan wrote:
Besides, float128 is a bad example - such a type could just be
returned directly where we return float64 now. (The only reason we
can't do that with Decimal is because we deliberately don't allow
In http://mail.python.org/pipermail/python-dev/2012-January/116003.html
Benjamin Peterson wrote:
2. It will be off by default in stable releases ... This will
prevent code breakage ...
2012/1/27 Steven D'Aprano steve at pearwood.info:
... it will become on by default in some future
In http://mail.python.org/pipermail/python-dev/2012-January/115715.html
Frank Sievertsen wrote:
Am 20.01.2012 13:08, schrieb Victor Stinner:
I'm surprised we haven't seen bug reports about it from users
of 64-bit Pythons long ago
A Python dictionary only uses the lower bits of a hash value.
PEP author Victor asked
(in http://mail.python.org/pipermail/python-dev/2012-February/116499.html):
Maybe I missed the answer, but how do you handle timestamp with an
unspecified starting point like os.times() or time.clock()? Should we
leave these function unchanged?
If *all* you know is
Eli Bendersky wrote (in
http://mail.python.org/pipermail/python-dev/2012-February/116393.html ):
A package will be marked provisional by including the
following paragraph as a note at the top of its
documentation page:
I really would like some marker available from within Python
itself.
201 - 226 of 226 matches
Mail list logo
