On 04/09/2016 07:32 AM, Nikolaus Rath wrote:
On Apr 07 2016, Donald Stufft wrote:
On Apr 7, 2016, at 6:48 AM, Nikolaus Rath wrote:
Does anyone anticipate any classes other than those from pathlib to come
with such a method?
It seems like it would be reasonable for pathlib.Path to call fspa
On 04/09/2016 12:48 AM, Nick Coghlan wrote:
> Considering the helper function usage, here's some examples in
> combination with os.fsencode and os.fsdecode:
>
> # Status quo for binary/text path conversions
> text_path = os.fsdecode(bytes_path)
> bytes_path = os.fsencode(text_path)
>
> #
On 04/10/2016 12:36 AM, Nick Coghlan wrote:
On 10 April 2016 at 17:12, Greg Ewing wrote:
But there needs to be some way to ask a path object for
its native string representation, otherwise there would
be no point in using foreign path objects at all.
In addition to the existing "str(pathobj)
On 04/09/2016 10:31 PM, Nick Coghlan wrote:
On 10 April 2016 at 02:41, Ethan Furman wrote:
When somebody hands you bytes rather than text you need to worry about
the encoding, and you need to worry about returning bytes rather than
text yourself. https://hg.python.org/cpython/rev/e44410e5928e
On 04/11/2016 07:56 AM, Antoine Pitrou wrote:
2) pathlib.Path accepts bytes --
Does it? Or are you proposing such a change?
It used to (I posted a couple examples from 3.5.0). I finally rebuilt
with the latest and it no longer does.
--
~Ethan~
On 04/10/2016 11:27 PM, Nick Coghlan wrote:
On 11 April 2016 at 02:16, Ethan Furman wrote:
DirEntry can still get the check, it can just throw TypeError when it
represents a binary path (that's one of the advantages of using a
method-based protocol - exceptions on method calls are
On 04/11/2016 09:32 AM, Zachary Ware wrote:
On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote:
If those examples are anywhere close to accurate, an fspath protocol that
supported both bytes and str seems a lot easier to work with.
But why are you working with bytes paths in the first
On 04/11/2016 10:36 AM, Brett Cannon wrote:
On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote:
I'm not saying that bytes paths are common -- and if this was a
brand-new feature I wouldn't be pushing for it so hard; however, bytes
paths are already supported and it seems to me to be
On 04/11/2016 11:35 AM, Guido van Rossum wrote:
Most excellent! PEP 506 is hereby approved. Congrats again.
Congratulations, Steven!
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
On 04/11/2016 12:00 PM, Brett Cannon wrote:
On Mon, 11 Apr 2016 at 11:28 Ethan Furman wrote:
I would write the above as:
def fspath(path, *, allow_bytes=False):
You get type consistency from so.fspath(), not the protocol, though.
Well, since the protocol is also a function, we could
On 04/11/2016 01:33 PM, Alexander Walters wrote:
In reviewing the ongoing arguments about how to make pathlib better,
there have been circular arguments about if it is even broken, if it
should support bytes, if there should be a path protocol that all
functions that touch the filesystem should
On 04/11/2016 01:42 PM, Victor Stinner wrote:
2016-04-11 21:00 GMT+02:00 Brett Cannon:
I'm -0 on allowing __fspath__ to return bytes, but we can see what others
think.
With the PEP 383, a bytes filename can be stored as str using the
surrogateescape error handler. So DirEntry can convert a b
On 04/11/2016 02:04 PM, Sven R. Kunze wrote:
On 11.04.2016 22:55, Alexander Walters wrote:
Every conceivable way to fix pathlib have already been argued. Are any
of them worth doing? Can we get consensus enough to implement one of
them? If not, we should consider either dropping the matter o
name:
We are down to two choices:
- __fspath__, or
- __fspathname__
The final choice I suspect will be affected by the choice to allow (or
not) bytes.
method or attribute:
---
method
built-in:
Almost - we'll put it in the os module
add to str:
--
On 04/11/2016 02:55 PM, Brett Cannon wrote:
That's pretty much it unless Chris or Ethan disagree. So I think pathlib
is far from being as dead as a parrot. ;)
That's nearly exactly what I wrote in my summary. :)
So, yes, we are nearly there!
--
~Ethan~
__
On 04/11/2016 01:42 PM, Victor Stinner wrote:
With the PEP 383, a bytes filename can be stored as str using the
surrogateescape error handler. So DirEntry can convert a bytes path to
str using os.fsdecode().
Does this mean that os.fsdecode() is simply a wrapper that sets the
errors to the sur
On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote:
Consider os.path.join:
Why in the world do the os.path functions need to work with Path
objects? ( and other conforming objects)
Because library XYZ that takes a path and wants to open it shouldn't
have to care whether that path is
On 04/11/2016 02:58 PM, Ethan Furman wrote:
Sticking points:
---
Do we allow bytes to be returned from os.fspath()? If yes, then do we
allow bytes from __fspath__()?
On 04/11/2016 10:28 PM, Stephen J. Turnbull wrote:
> In text applications, "bytes as carcinogen&qu
On 04/11/2016 04:43 PM, Victor Stinner wrote:
Le 11 avr. 2016 11:11 PM, "Ethan Furman" a écrit :
So my concern in such a case is what happens if we pass this SE
string somewhere else: a UTF-8 file, or over a socket, or into a
database? Does this have issues that we wouldn't
On 04/12/2016 09:20 AM, Chris Angelico wrote:
On Wed, Apr 13, 2016 at 2:15 AM, Ethan Furman
latin1? I thought latin1 had a code point for 0-255, so how could using it
raise an encoding error?
Latin-1 / ISO-8859-1 defines a character for every byte, so any byte
string will *decode*. It only
On 04/12/2016 09:26 AM, Koos Zevenhoven wrote:
So I'm, once again, posing this question (that I don't think got any
reactions previously): Is there a significant audience for this new
function, or is it enough to keep it a private function for the stdlib
to use?
Quite frankly, I expect the std
On 04/13/2016 07:21 AM, Nick Coghlan wrote:
On 14 April 2016 at 00:11, Paul Moore wrote:
On 13 April 2016 at 14:51, Nick Coghlan wrote:
The potential SE-strings only come back when you pass str, and the
operating system data isn't properly encoded according to the nominal
filesystem encoding.
On 04/13/2016 08:17 AM, Random832 wrote:
On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote:
I'd expect the main consumers to be os and os.path, and would honestly
be surprised if we needed many explicit invocations above that layer,
other than in pathlib itself.
I made a toy implementation
On 04/13/2016 09:18 AM, Fred Drake wrote:
On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote:
- a single os.fspath() with an allow_bytes parameter
(mostly True in os and os.path, mostly False everywhere
else)
-0
- a str-only os.fspathname() and a str/bytes os.fspath()
+1 on using
On 04/13/2016 09:27 AM, Paul Moore wrote:
On 13 April 2016 at 17:18, Fred Drake wrote:
Names like os.fspath() and os.fssyspath() seem good to me.
-1 on fssyspath - the "system" representation is bytes on POSIX, but
not on Windows. Let's be explicit and go with fsbytespath().
It will be con
On 04/13/2016 09:58 AM, Brett Cannon wrote:> On Wed, 13 Apr 2016 at
09:19 Fred Drake wrote:
>> I do the same, but... this is one of those cases where a caller will
>> usually be passing a constant directly. If passed as a positional
>> argument, it'll just be confusing ("what's True?" is my usua
On 04/13/2016 10:22 AM, Alexander Walters wrote:
On 4/13/2016 13:10, Brett Cannon wrote:
https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1
has the four potential approaches implemented (although it doesn't
follow the "separate functions" approach some are proposing and
inste
On 04/13/2016 03:45 PM, Nikolaus Rath wrote:
When passing an object that is of type str and has a __fspath__
attribute, all approaches return the value of __fspath__().
However, when passing something of type bytes, the second approach
returns the object, while the third returns the value of __
On 04/13/2016 05:06 PM, Chris Barker wrote:
In this case, I don't know that we need to be tolerant of buggy
__fspathname__() implementations -- they should be tested outside these
checks, and not be buggy. So a buggy implementation may raise and may be
ignored, depending on what Exception the bu
On 04/13/2016 07:57 PM, Nikolaus Rath wrote:
On Apr 13 2016, Ethan Furman wrote:
On 04/13/2016 03:45 PM, Nikolaus Rath wrote:
When passing an object that is of type str and has a __fspath__
attribute, all approaches return the value of __fspath__().
However, when passing something of type
On 04/14/2016 12:03 AM, Michael Mysinger via Python-Dev wrote:
Brett Cannon writes:
After playing with and considering the 4 possibilities, anything where
__fspath__ can return bytes seems like insanity that flies in the face of
everything Python 3 is trying to accomplish. In particular, one R
On 04/14/2016 05:16 AM, Victor Stinner wrote:
I consider that the final goal of the whole discussion is to support
something like:
path = os.path.join(pathlib_path, "str_path", direntry)
Even if direntry uses a bytes filename. I expect genericpath.join() to
be patched to use os.fspath().
On 04/14/2016 06:56 AM, Victor Stinner wrote:
2016-04-14 15:40 GMT+02:00 Nick Coghlan:
>> Even earlier, Victor Stinner wrote:
I consider that the final goal of the whole discussion is to support
something like:
path = os.path.join(pathlib_path, "str_path", direntry)
That's not a *new*
On 04/14/2016 07:52 AM, Stephen J. Turnbull wrote:
Nick Coghlan writes:
The use case for returning bytes from __fspath__ is DirEntry, so you
can write things like this in low level code:
def myscandir(dirpath):
for entry in os.scandir(dirpath):
if entry.is_file():
On 04/14/2016 07:01 AM, Random832 wrote:
On Thu, Apr 14, 2016, at 09:50, Chris Angelico wrote:
Adding integers and floats is considered "safe" because most people's
use of floats completely compasses their use of ints. (You'll get
OverflowError if it can't be represented.) But float and Decimal
On 04/14/2016 09:09 AM, Victor Stinner wrote:
2016-04-14 16:54 GMT+02:00 Ethan Furman:
I consider that the final goal of the whole discussion is to support
something like:
path = os.path.join(pathlib_path, "str_path", direntry)
(...)
I expect that DirEntry.__fspath__ uses o
On 04/14/2016 08:59 AM, Michael Mysinger via Python-Dev wrote:
I am saying that if os.path.join now accepts RichPath objects, and those
objects can return either str or bytes, then its much harder to reason about
when I have all bytes or all strings. In essence, you will force me to pre-
wrap al
On 04/14/2016 10:02 AM, Random832 wrote:
"between versions" is ambiguous. It could mean that there's no guarantee
that there will be no changes from one version to the next, or it could
mean, even more strongly, that there's no guarantee that there will be
no changes in a maintenance release (wh
On 04/14/2016 10:22 AM, Paul Moore wrote:
On 14 April 2016 at 17:46, Ethan Furman wrote:
If you are not working at the bytes layer, you shouldn't be getting bytes
objects because:
- you specified str when asking for data from the OS, or
- you transformed the incoming bytes from wha
On 04/13/2016 02:37 PM, Victor Stinner wrote:
I'm not a big fan of a flag parameter to change the return type of a
function. Usually, two functions are preferred. In the os module we have
getcwd/getcwdb for example. I don't know if it's a good example
I think of os.fspath() as more of a filter
On 04/14/2016 05:20 PM, Stephen J. Turnbull wrote:
However, the proposed polymorphism does create ambiguity and risk for
my uses. I rarely have the luxury of *not* ensuring paths are text,
regardless of the bytes-ness of the underlying application, because I
can be pretty darn sure that somebod
On 04/14/2016 06:01 PM, Ethan Furman wrote:
On 04/14/2016 05:20 PM, Stephen J. Turnbull wrote:
you'll have to impose it on me.
Hmm. Well, the good news is you have convinced me that letting bytes
through willy-nilly is akin to loosing the hounds of hell on our code.
The bad news is
On 04/15/2016 01:41 PM, Victor Stinner wrote:
2016-04-15 19:54 GMT+02:00 Jim J. Jewett:
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
It's an useful property. For example, let's say that you have a guard
on globals()['value']. The guard is created with
On 04/17/2016 06:58 AM, Koos Zevenhoven wrote:
So, as a summary: With a str+bytes-polymorphic __fspath__, with the
above argumentation and the rough implementation of os.fspath(...),
the conclusion is that the os.fspath function should indeed be public,
and that no further variations are needed.
On 04/17/2016 02:05 PM, Koos Zevenhoven wrote:
On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman wrote:
On 04/17/2016 06:58 AM, Koos Zevenhoven wrote:
So, as a summary: With a str+bytes-polymorphic __fspath__, with the
above argumentation and the rough implementation of os.fspath(...),
the
On 04/18/2016 12:41 AM, Nick Coghlan wrote:
Given the variant you [Koos] suggested, what if we defined the API semantics
like this:
# Offer the simplest possible API as the public vesion
def fspath(pathlike) -> str:
return os._raw_fspath(pathlike)
# Expose the complexit
On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote:
Koos Zevenhoven writes:
After all, we want something that's *almost* exclusively str.
But we don't want that, AFAICT. Some clearly want this API to be
unbiased against bytes in the same way the os APIs are unbiased[2],
because that's what w
On 04/18/2016 12:54 PM, Wes Turner wrote:
Don't we *have* to always support bytes because other programs can
create filenames containing bytes?
Yes, but not every function has to support bytes.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@pyth
On 04/18/2016 02:58 PM, Koos Zevenhoven wrote:
It's a matter of documentation whether it "supports" bytes
or not. In fact, that function (assuming the name os.fspath) could now
even be documented to support this:
patharg = os.fspath(patharg, output_types = (str, pathlib.PurePath)) # :-)
On 04/18/2016 12:26 PM, Stephen J. Turnbull wrote:
I haven't looked at Antipathy, but I would guess from Ethan's
promotion of bytes paths and concern with efficiency that "bytes
antipaths" do *not* "go through" str to get to bytes, they already are
bytes (in the sense of class inheritance).
Co
On 04/20/2016 04:52 AM, Victor Stinner wrote:
Can you please wait for a PEP? Brett Canon and Ethan Furman are
working on a PEP.
Actually, Brett Canon and Chris Angelico.
> So please give them time to write it.
Okay, I'll shut-up now. ;)
-
On 04/20/2016 04:52 AM, Victor Stinner wrote:
FYI there is already an article about fspath/pathlib on LWN. Here is a
free link until the article is freely accessible:
"Python looks at paths" By Jake Edge (April 13, 2016)
https://lwn.net/SubscriberLink/683350/4f52334af09653c8/
Nice article, th
On 04/24/2016 12:20 AM, Xavier de Gaye wrote:
[1] https://bitbucket.org/xdegaye/pyona/src
The license:
---
This software is licensed under the GNU General Public License version 3
or later.
---
Will combining your code with Python 3 be a problem?
--
~Ethan~
___
On 04/28/2016 08:26 AM, Stefan Krah wrote:
Random832 writes:
A more relevant point would be that _decimal does *not* use the API in a
way *which would be broken by the proposed change*, regardless of
whether the way in which it uses it is subjectively correct or can cause
leaks.
And the ulti
I just reviewed an issue on the tracker, and found that many, if not
all, of my comments made at the time I completely disagree with (both
now, and before -- I'm going to claim sleep deprivation).
Obviously I should post a new comment explaining my thoughts about the
issue, but what should I d
On 05/07/2016 03:39 PM, Serhiy Storchaka wrote:
Some types have alternative constructors -- class methods used to create
an instance of the class. For example: int.from_bytes(),
float.fromhex(), dict.fromkeys(), Decimal.from_float().
But what should return these methods for subclasses? Should th
On 05/07/2016 04:06 PM, Ethan Furman wrote:
I just reviewed an issue on the tracker, and found that many, if not
all, of my comments made at the time I completely disagree with (both
now, and before -- I'm going to claim sleep deprivation).
Obviously I should post a new comment explaini
Currently, the Enum creation process ignores __dunder__ attributes, and
blocks all _sunder_ attributes.
Because of this, the enum34 backport used __order__ instead of _order_
to provide a mechanism for ordering the enum members (which I never
really liked).
However, I've been working on my a
On 05/08/2016 03:29 PM, Guido van Rossum wrote:
If enum were provisional it would be okay, but since it isn't, I think
this change can't go into 3.5.2. Think if this: could any code that
works in 3.5.1 be broken by the change?
No, but with the change code that works in 3.5.2 could break in 3.5
On 05/08/2016 03:52 PM, Guido van Rossum wrote:
I think it's a case of water under the bridge and learning to live with
your mistakes.
Better than dying from them.
:)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
On 05/08/2016 07:15 PM, Nick Coghlan wrote:
On 9 May 2016 at 08:43, Ethan Furman wrote:
It's a 2/3 compatibility issue with enum34 and aenum which support _order_,
and Python3.4+ which does not. The work-around is to use __order__ instead
(or use enum34 or aenum instead ;) .
Needing t
On 05/11/2016 01:44 PM, Serhiy Storchaka wrote:
os.path
'''
The various path-manipulation functions of ``os.path`` [#os-path]_
will be updated to accept path objects. For polymorphic functions that
accept both bytes and strings, they will be updated to simply use
code very much similar to
`
On 05/11/2016 01:51 PM, Ethan Furman wrote:
On 05/11/2016 01:44 PM, Serhiy Storchaka wrote:
os.path
'''''''
The various path-manipulation functions of ``os.path`` [#os-path]_
will be updated to accept path objects. For polymorphic functions that
accept b
On 05/11/2016 02:28 PM, Nikolaus Rath wrote:
On May 11 2016, Brett Cannon wrote:
This PEP proposes a protocol for classes which represent a file system
path to be able to provide a ``str`` or ``bytes`` representation.
[...]
As I said before, to me this seems like a lot of effort for a very
s
On 05/11/2016 03:13 PM, Brett Cannon wrote:
If [...] I would drop os.path changes and make os.fspath() do what
> Ethan and Koos have suggested and simply pass through without checks
whatever path.__fspath__() returned if the argument wasn't str or bytes.
Not to derail the conversation too mu
On 05/11/2016 05:13 PM, Arthur Darcet wrote:
os.path.getmtime could be used in a tight loop, to sync directories with
a lot of files for instance.
% python3 -m timeit -s "import os.path; p = 'out'" "hasattr(p,
'__fspath__'), os.path.getmtime(p)"
10 loops, best of 3: 2.67 usec per loop
% pyt
On 05/11/2016 09:55 PM, Serhiy Storchaka wrote:
[...] But for example os.walk() was significantly
boosted with using os.scandir(), it would be sad to make it slower
again.
scandir's speed improvement is due to not not throwing away data the OS
was already giving us.
os.path is used in num
On 05/12/2016 01:31 AM, Sven R. Kunze wrote:
I think the "Rationale" section ignores the fact the Path also supports
the .path attribute now. Which indeed defines a common interface between
path objects.
The version of Python that has Path.path has not been released yet. And
even so, .path i
On 05/12/2016 09:26 AM, Sven R. Kunze wrote:
On 12.05.2016 17:42, Ethan Furman wrote:
On 05/12/2016 01:31 AM, Sven R. Kunze wrote:
I think the "Rationale" section ignores the fact the Path also supports
the .path attribute now. Which indeed defines a common interface between
pa
On 05/12/2016 10:21 AM, Sven R. Kunze wrote:
On 12.05.2016 18:56, Ethan Furman wrote:
On 05/12/2016 09:26 AM, Sven R. Kunze wrote:
str and bytes will receive the __fspath__ attribute when this PEP is
accepted?
No, they won't. The __fspath__ protocol will reduce the rich path
object
On 05/12/2016 10:22 AM, Sjoerd Job Postmus wrote:
However, if it were to reject bytes, that would mean that when libraries
start to use pathlib, it would suddenly become harder for people that
actually need bytes-support to use pathlib.
pathlib is not about bytes support. While bytes are nece
On 05/12/2016 01:59 PM, Sjoerd Job Postmus wrote:
On 12 May 2016, at 21:30, Ethan Furman wrote:
If you need bytes support for your paths, there's at least one [1] that has
that support.
So if I would need bytes support, I should submit a pull request to > library> which replac
On 05/13/2016 08:43 AM, Brett Cannon wrote:
a minor technical query:
try:
return path.__fspath__()
Would I be right in saying that in practice this will actually end up
being type(path).__fspath__() to match the behaviour of all(?) other
dunder methods?
I wasn't planning
On 05/13/2016 09:06 AM, Sven R. Kunze wrote:
On 13.05.2016 11:48, Koos Zevenhoven wrote:
>> Sven R Kunze had previously queried:
However, the proposed semantics will change if the checks are swapped. So,
my actual question is:
Is that an intended API inconsistency or a known bug supposed to b
On 05/16/2016 02:32 PM, Brett Cannon wrote:
PEP 519 is now marked as accepted! Two PEPs accepted in one day (Nick
approved 518 earlier)!
Excellent! :)
If pathlib doesn't get updated in 3.4, 3.5, and 3.6 before PyCon it will
be the first thing I do at the sprints so that it isn't an issue fo
On 05/18/2016 11:52 AM, Neil Schemenauer wrote:
Benjamin Peterson wrote:
Adding PyGC_CollectIfEnabled() and calling it in Py_Finalize is probably
fine. I don't think the contract of PyGC_Collect itself (or gc.collect()
for that matter) should be changed. You might want to disable GC but
invoke
On 05/20/2016 09:27 AM, Brett Cannon wrote:
Is there a specific reason for calling out two spaces in comments after
a period(I realize it's probably for consistency, but I sure don't ever
think about this when I write comment)? Otherwise who actually still
writes using two spaces after punctuati
For binary methods, such as __add__, either do not implement or return
NotImplemented if the other operand/class is not supported.
For non-binary methods, simply do not define.
Except for subclasses when the super-class defines __hash__ and the
subclass is not hashable -- then set __hash__ to
On 06/07/2016 10:51 AM, Eric Snow wrote:
My intention was to land the patch soon, having gone through code
review during PyCon. However, Nick pointed out to me the benefit of
having a concrete point of reference for the change, as well as making
sure it isn't a problem for other implementations
On 10/20/2013 07:42 PM, Raymond Hettinger wrote:
In short, I recommend that efforts be directed at improving help() rather than
limiting introspection by way of less clean coding practices.
+1
We also have the option of adding a custom __dir__ to change what help()
displays.
--
~Ethan~
___
Nikolaus,
Good write-up. Please submit it to the bug tracker: http://bugs.python.org
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options
On 10/26/2013 08:32 PM, Nikolaus Rath wrote:
Ethan Furman writes:
Good write-up. Please submit it to the bug tracker:
http://bugs.python.org
Submitted as http://bugs.python.org/issue19414.
If someone gives me the go-ahead for one of the proposed solutions, I'd
be happy to create a
On 10/30/2013 12:12 AM, Raymond Hettinger wrote:
Hopefully, this post will make the thought process more transparent.
Thanks, Raymond. Your time is appreciated.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
On 10/30/2013 09:34 AM, Nigel Small wrote:
It strikes me that there could be an alternative approach to some of the use
cases discussed here. Instead of a new type
of dictionary, the case-insensitivity problem could be solved with something
akin to a *CaseInsensitiveString* class [...]
The n
On 10/31/2013 05:20 AM, Victor Stinner wrote:
I did another experiment. I replaced enable/disable/is_enabled with
start/stop/is_tracing, and added enable/disable/is_enabled functions
to disable temporarily tracing.
API:
- clear_traces(): clear traces
- start(): start tracing (the old "enable")
On 11/04/2013 07:52 AM, Guido van Rossum wrote:
Two more approaches that can help when you haven't pushed yet:
- hg rollback undoes the most recent local commit while leaving the local
workspace unchanged so the files are now
patched but not committed
- hg strip deletes a revision and all its
On 11/05/2013 04:55 AM, Eric V. Smith wrote:
I love all things British, but the python source code usually uses
"customiz*" (341 instances) over "customis*" (19 instance, 8 of which
are in logging).
I realize "foolish consistency", and all that, but I think the
documentation should all use the
http://bugs.python.org/issue19332
Summary:
--> d = {1: 'one'}
--> for k in d:
... d[k+1] = d[k] * k
...
Traceback (most recent call last):
File "", line 1, in
RuntimeError: dictionary changed size during iteration
--> for k in d:
... del d[k]
...
Traceback (most recent call last):
File
Thank you, Raymond, and everyone else who responded both here and on the
tracker.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
On 11/08/2013 11:49 AM, Eric Snow wrote:
I'm pleased to announce that Brett Cannon and Nick Coghlan (the
co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4.
Excellent! Congrats, and thanks to everyone who worked on it.
--
~Ethan~
_
On 11/14/2013 02:59 PM, Terry Reedy wrote:
On 11/14/2013 4:55 PM, Tres Seaver wrote:
About the only things I can think of which might break would be doctests,
but people *expect* those to break across third-dot releases of Python
(one reason why I hate them).
My impression is that we avoid en
On 11/14/2013 11:13 PM, Nick Coghlan wrote:
The proposal I posted to issue 7475 back in April (and, in the absence
of any objections to the proposal, finally implemented over the past
few weeks) was to take advantage of the fact that the codecs.encode
and codecs.decode convenience functions exis
On 11/15/2013 02:24 PM, Christian Tismer wrote:
I appreciate very much that Victor tried his best to fill that old gap.
And after that breakage happened again, I think it is urgent to have an
> in-depth discussion how that situation should be treated in the
> future.
+1
--
~Ethan~
__
On 11/20/2013 04:25 AM, Garth Bushell wrote:
I'm also quite uneasy on the case insensitive comparison on Windows as the File
system NTFS is case sensitive.
No, it's case-preserving.
"""Current Windows file systems, like NTFS, are case-sensitive; that is a
readme.txt and a Readme.txt can ex
On 11/21/2013 10:53 AM, Christian Tismer wrote:
So even if VS2010 exists only in the stackless branch, it is very likely
to get used as CPython VS 2010, and I again have the naming problem ...
What's wrong with calling it CPython VS 2010? And Stackless VS 2010?
--
~Ethan~
On 11/22/2013 01:00 AM, Richard Tew wrote:
[snip]
Yet, suddenly, the chance that we may release a "Stackless Python
2.8", is a concern.
Because there is no CPython 2.8 to mirror, and we've said there will not be one.
It certainly didn't help that this was presented one week before the featur
[Redirecting to Python Dev]
On 11/22/2013 10:25 AM, Richard Tew wrote:
On Sat, Nov 23, 2013 at 3:16 AM, Ethan Furman wrote:
On 11/22/2013 01:00 AM, Richard Tew wrote:
Yet, suddenly, the chance that we may release a "Stackless Python
2.8", is a concern.
Because there is no CPyt
On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
How would you get the docstrings in? [...]
One way to reduce the amount of boilerplate code is to make abstractmethod
to supply raise NotImplementedError body when none is given. Then
On 12/05/2013 12:39 PM, MRAB wrote:
On 05/12/2013 19:22, Ethan Furman wrote:
On 12/05/2013 10:56 AM, Alexander Belopolsky wrote:
On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote:
How would you get the docstrings in? [...]
One way to reduce the amount of boilerplate code is to make
On 12/05/2013 10:20 AM, Allen Li wrote:
90% of the time, it ends up looking something like this:
class Foo(metaclass=abc.ABCMeta):
@abc.abstractmethod
def f1(self):
raise NotImplementedError
@staticmethod
@abc.abstractmethod
def f2(arg1):
raise NotIm
401 - 500 of 1590 matches
Mail list logo
