On 06/23/2014 01:04 PM, Antoine Pitrou wrote:
Le 23/06/2014 15:27, M.-A. Lemburg a écrit :
Not sure what you mean. We've had binary wininst distributions
for Windows for more than a decade, and egg and msi distributions
for 8 years :-)
But without access to the VS 2008 compiler that is needed
On 06/21/2014 02:48 PM, Ethan Furman wrote:
On 06/21/2014 02:37 PM, M.-A. Lemburg wrote:
My answers to these are: 1. We should use dynamic linking
instead and not let OpenSSL bugs trigger Python releases; 2.
It's not a big problem; 3. Yes, please, since it is difficult
for people to de
On 06/24/2014 12:54 PM, Ned Deily wrote:
Yes, we are committed to maintaining
Python 2.7 for multiple years but that doesn't mean we have to fix every
open issue or even most open issues. Any or all of the above costs may
apply to any changes we make. For many of our users, the best
maintenanc
On 06/26/2014 04:36 PM, Tim Delaney wrote:
On 27 June 2014 09:28, MRAB wrote:
Personally, I'd prefer the name 'iterdir' because it emphasises that
it's an iterator.
Exactly what I was going to post (with the added note that thee's an obvious
symmetry with listdir).
+1 for iterdir rather tha
On 06/29/2014 05:28 AM, Nick Coghlan wrote:
So, here's my alternative proposal: add an "ensure_lstat" flag to
scandir() itself, and don't have *any* methods on DirEntry, only
attributes.
That would make the DirEntry attributes:
is_dir: boolean, always populated
is_file: boolean, alwa
On 06/29/2014 04:12 AM, Jonas Wielicki wrote:
If the flag is set to False, all the fields in the DirEntry will be
None, for consistency, even on Windows.
-1
This consistency is unnecessary.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.o
On 06/30/2014 03:07 PM, Tim Delaney wrote:
On 1 July 2014 03:05, Ben Hoyt wrote:
So, here's my alternative proposal: add an "ensure_lstat" flag to
scandir() itself, and don't have *any* methods on DirEntry, only
attributes.
...
Most importantly, *regardless of platform*, the cached stat result
On 06/30/2014 04:15 PM, Tim Delaney wrote:
On 1 July 2014 08:38, Ethan Furman wrote:
On 06/30/2014 03:07 PM, Tim Delaney wrote:
I'm torn between whether I'd prefer the stat fields to be populated
on Windows if ensure_lstat=False or not. There are good arguments each
way, but o
On 06/30/2014 06:28 PM, Ben Hoyt wrote:
I suppose the exact behavior is still under discussion, as there are only
two or three fields one gets "for free" on Windows (I think...), where as an
os.stat call would get everything available for the platform.
No, Windows is nice enough to give you all
On 07/01/2014 07:59 AM, Jonas Wielicki wrote:
I had the idea to treat a failing lstat() inside scandir() as if the
entry wasn’t found at all, but in this context, this seems wrong too.
Well, os.walk supports passing in an error handler -- perhaps scandir should as
well.
--
~Ethan~
__
On 07/01/2014 02:20 PM, Paul Moore wrote:
Please, let's stick to a low-level wrapper round the OS API for the
first iteration of this feature. Enhancements can be added later, when
real-world usage has proved their value.
+1
___
Python-Dev mailing li
On 07/07/2014 04:22 AM, Andreas Maier wrote:
Where is the discrepancy between the documentation of == and its default
implementation on object documented?
There's seems to be no discrepancy (at least, you have not shown it), but to answer the question about why the default
equals operation i
On 07/07/2014 09:56 AM, Andreas Maier wrote:
Am 07.07.2014 17:55, schrieb Ethan Furman:
On 07/07/2014 04:22 AM, Andreas Maier wrote:
Where is the discrepancy between the documentation of == and its
default implementation on object documented?
There's seems to be no discrepancy (at
On 07/07/2014 12:01 PM, francis wrote:
On 06/23/2014 10:12 PM, R. David Murray wrote:
The stats graphs are based on the data generated for the
weekly issue report. I have a patched version of that
report that adds the bug/enhancement info. I'll try to dig
it up this week; someone ping me if I
On 07/07/2014 08:29 AM, Andreas Maier wrote:
So the Python 2.7 implementation shows the same discrepancy as Python 3.x
regarding the == and != default implementation.
Why do you see this as a discrepancy?
Just because two instances from the same object have the same value does not mean they
On 07/07/2014 04:36 PM, Andreas Maier wrote:
Am 2014-07-07 19:43, schrieb Ethan Furman:
Python cannot know which values are important in an equality test, and which
are not. So it refuses to guess.
Well, one could argue that using the address of an object for its value
equality test is
On 07/07/2014 04:49 PM, Benjamin Peterson wrote:
Probably the best argument for the behavior is that "x is y" should
imply "x == y", which preludes raising an exception. No such invariant
is desired for ordering, so default implementations of < and > are not
provided in Python 3.
Nice. This b
On 07/07/2014 05:12 PM, Andreas Maier wrote:
Am 2014-07-07 18:09, schrieb Ethan Furman:
Just because two instances from the same object have the same value does not
mean they are equal. For a real-life
example, look at twins: biologically identical, yet not equal.
I think they *are* equal
On 07/07/2014 06:58 PM, Steven D'Aprano wrote:
On Mon, Jul 07, 2014 at 04:52:17PM -0700, Ethan Furman wrote:
On 07/07/2014 04:49 PM, Benjamin Peterson wrote:
Probably the best argument for the behavior is that "x is y" should
imply "x == y", which preludes rais
On 07/07/2014 06:18 PM, Andreas Maier wrote:
Am 2014-07-08 01:50, schrieb Ethan Furman:
I never add __eq__ to my classes until I come upon a place where I need to
check if two instances of those classes are
'equal', for whatever I need equal to mean in that case.
With that str
On 07/07/2014 08:34 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
And what would be this 'sensible definition' [of value equality]?
I think that's the wrong question. I suppose Andreas's point is that
when the programmer doesn't provide a definition, th
On 07/08/2014 11:05 AM, Ben Hoyt wrote:
Only exposing what the OS provides for free will make the API too difficult
to use in the common case. But is there a nice way to expand the API that
will allow the user who is trying to avoid extra expense know what
information is already available?
Even
On 07/08/2014 12:34 PM, Ben Hoyt wrote:
Better to just have the attributes be None if they were not fetched. None
is better than hasattr anyway, at least in the respect of not having to
catch exceptions to function properly.
The thing is, is_dir() and lstat() are not attributes (for a good
re
On 07/08/2014 01:22 PM, Ethan Furman wrote:
I think caching the attributes for DirEntry is fine, but let's do it as a
snapshot of that moment in time, not name now,
and attributes in 30 minutes when we finally get to you because we had a lot of
processing/files ahead of you (you be
On 07/08/2014 06:08 PM, Ben Hoyt wrote:
Just like an attribute does not imply a system call, having a
method named 'is_dir' /does/ imply a system call, and not
having one can be just as misleading.
Why does a method imply a system call? os.path.join() and str.lower()
don't make system calls. I
On 07/09/2014 05:48 AM, Ben Hoyt wrote:
So how about tweaking option #2 a tiny bit more to this:
def scandir(path='.', info=None, onerror=None): ...
* if info is None (the default), only the .name and .full_name
attributes are present
* if info is 'type', scandir ensures the is_dir/is_file/is_
On 07/09/2014 06:22 AM, Ben Hoyt wrote:
One issue with option #2 that I just realized -- does scandir yield the entry
at all if there's a stat error? It
can't really, because the caller will expect the .lstat attribute to be set
(assuming he asked for type='lstat') but
it won't be. Is effectiv
On 07/09/2014 06:41 AM, Ethan Furman wrote:
Leave it up to the onerror handler. If it returns None, skip yielding the
entry, otherwise yield whatever it returned
-- which also means the error handler should be able to set fields on the
DirEntry:
def log_err(exc, entry
On 07/09/2014 08:35 AM, Ben Hoyt wrote:
One issue with option #2 that I just realized -- does scandir yield the
entry at all if there's a stat error? It
can't really, because the caller will expect the .lstat attribute to be
set (assuming he asked for type='lstat') but
it won't be. Is effectivel
On 07/09/2014 10:10 AM, Paul Moore wrote:
On 9 July 2014 14:22, Ben Hoyt wrote:
One issue with option #2 that I just realized -- does scandir yield
the entry at all if there's a stat error? It can't really, because the
caller will except the .lstat attribute to be set (assuming he asked
for typ
On 07/09/2014 11:04 AM, Paul Moore wrote:
On 9 July 2014 17:35, Ethan Furman wrote:
More specifically, if we go with choice 1 (no built-in error handling, no
mutable DirEntry), how would I implement choice 2? Would I have to write my
own CustomDirEntry object?
Having built-in error handling
On 07/09/2014 12:03 PM, Ben Hoyt wrote:
So here's the ways in which option #2 is now more complicated than option #1:
1) it has an additional "info" argument, the values of which have to
be documented ('os', 'type', 'lstat', and what each one means)
2) it has an additional "onerror" argument, t
On 07/09/2014 01:57 PM, Paul Moore wrote:
On 9 July 2014 21:24, Victor Stinner wrote:
Example where you may sometimes need is_dir(), but not always
---
for entry in os.scandir(path):
if ignore_entry(entry.name):
# this entry is not interesting, lstat_result is useless here
contin
On 07/09/2014 01:24 PM, Victor Stinner wrote:
Sorry, I didn't follow the whole discussion. IMO DirEntry must use
methods and you should not expose nor document which infos are already
provided by the OS or not. DirEntry should be a best-effort black-box
object providing an API similar to pathlib
On 07/09/2014 02:42 PM, Ben Hoyt wrote:
Okay, so using that [no platform specific] logic we should head over to the os
module and remove:
ctermid, getenv, getegid...
Okay, I'm tired of typing, but that list is not even half-way through the os
page, and those are all methods or attributes that
On 07/09/2014 02:38 PM, Victor Stinner wrote:
2014-07-09 22:44 GMT+02:00 Ethan Furman:
On 07/09/2014 01:24 PM, Victor Stinner wrote:
[...] Python must remain
portable and you should not write code specific to one specific
platform.
Okay, so using that logic we should head over to the os
On 07/09/2014 02:33 PM, Ben Hoyt wrote:
On a system which did not supply is_dir automatically I would write that as:
for entry in os.scandir(path):
if ignore_entry(entry.name):
continue
if os.path.isdir(entry.full_name):
# do something interesting
Not har
On 07/09/2014 04:22 PM, MRAB wrote:
On 2014-07-09 23:50, Ethan Furman wrote:
Okay, marry the two ideas together:
scandir(path, info=None, onerror=None)
"""
Return a generator that returns one directory entry at a time in a
DirEntry object
Should that be &
On 07/09/2014 05:15 PM, Victor Stinner wrote:
2014-07-09 17:29 GMT+02:00 Ben Hoyt :
Would this not "break" the tree size script being discussed in the
other thread, as it would follow links and include linked directories
in the "size" of the tree?
The get_tree_size() function in the PEP would
On 07/10/2014 06:58 AM, Nick Coghlan wrote:
The info we want for scandir is that of the *link itself*. That makes it
easy to implement things like the "followlinks" flag of os.walk. The
*far end* of the link isn't relevant at this level.
This also mirrors listdir, correct? scandir is simply*
On 07/10/2014 04:57 PM, Alexander Belopolsky wrote:
On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence wrote:
I'm just curious as to why there are 54 open issues after both of
these PEPs have been accepted and 384 is listed as finished. Did
we hit some unforeseen technical problem which stalled d
On 07/09/2014 09:02 PM, Nick Coghlan wrote:
On 9 Jul 2014 17:14, "Ethan Furman" wrote:
I like the 'onerror' API better primarily because it gives a single
point to deal with the errors. [...]
The "onerror" approach can also deal with readdir failing, which t
On 07/11/2014 07:04 AM, Andreas Maier wrote:
Am 09.07.2014 03:48, schrieb Raymond Hettinger:
Personally, I see no need to make the same mistake by removing
the identity-implies-equality rule from the built-in containers.
There's no need to upset the apple cart for nearly zero benefit.
Contain
On 07/13/2014 08:13 AM, Andreas Maier wrote:
Am 11.07.2014 22:54, schrieb Ethan Furman:
Here is the externally visible behavior:
Python 3.5.0a0 (default:34881ee3eec5, Jun 16 2014, 11:31:20)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "lic
On 07/13/2014 05:33 PM, Ben Hoyt wrote:
On the recent python-dev thread, Victor especially made some well
thought out suggestions. It seems to me there's general agreement that
the basic API in PEP 471 is good (with Ethan not a fan at first, but
it seems he's on board after further discussion :-
On 07/13/2014 10:33 PM, Andreas Maier wrote:
Am 14.07.2014 04:55, schrieb Ethan Furman:
On 07/13/2014 08:13 AM, Andreas Maier wrote:
Test #8: Same object of class C
(C.__eq__() implemented with equality of x,
C.__ne__() returning NotImplemented):
obj1: type=, str=C(256), id
has now been dead for five months.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 07/14/2014 10:43 AM, Skip Montanaro wrote:
On Mon, Jul 14, 2014 at 11:59 AM, Brett Cannon wrote:
This is the wrong place to ask about this. It falls under the purview of the
web site who you can email at webmaster@ or submit an issue at
https://github.com/python/pythondotorg . But I know fro
On 07/14/2014 06:01 PM, Wes Turner wrote:
From
http://www.reddit.com/r/Python/comments/17c69p/i_was_told_by_a_friend_that_learning_python_for/c84bswd
:
* http://www.python.org/community/jobs/
* https://jobs.github.com/positions?description=python
* http://careers.joelonsoftware.com/jobs?searc
On 07/14/2014 07:48 PM, Ben Hoyt wrote:
In any case, here's the modified proposal:
scandir(path='.') -> generator of DirEntry objects, which have:
* name: name as per listdir()
* full_name: full path name (not necessarily absolute), equivalent of
os.path.join(path, entry.name)
* is_dir(follow_
On 07/14/2014 11:25 PM, Victor Stinner wrote:
Again: remove any garantee about the cache in the definitions of methods,
instead copy the doc from os.path and os. Add a global remark saying that
most methods don't need any syscall in general, except for symlinks (with
follow_symlinks=True).
I
On 07/21/2014 03:26 PM, Victor Stinner wrote:
The PEP is accepted.
Thanks, Victor!
Congratulations, Ben!
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyt
On 08/04/2014 12:12 AM, Larry Hastings wrote:
It's my contention that "nullable" is the correct name. But I've been asked to
bring up the topic for discussion, to
see if a consensus forms around this or around some other name.
Let the bike-shedding begin,
I think the original name is okay,
On 08/07/2014 03:06 PM, Chris Barker wrote:
[snip timings, etc.]
I don't remember where, but I believe that cPython has an optimization built in for repeated string concatenation, which
is probably why you aren't seeing big differences between the + and the sum().
A little testing shows how t
On 08/07/2014 04:01 PM, Ethan Furman wrote:
On 08/07/2014 03:06 PM, Chris Barker wrote:
the + and the sum().
Yeah, that 'sum' should be 'join' :/
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mai
On 08/07/2014 04:01 PM, Ethan Furman wrote:
On 08/07/2014 03:06 PM, Chris Barker wrote:
--> timeit.Timer("for string in ['booya'] * 10: blah = blah + string", "blah =
''").repeat(3, 1)
[0.021117210388183594, 0.013692855834960938, 0.00768280
On 08/08/2014 08:23 AM, Chris Barker wrote:
So my final question is this:
repeated string concatenation is not the "recommended" way to do this -- but
nevertheless, cPython has an optimization
that makes it fast and efficient, to the point that there is no practical
performance reason to pref
On 08/08/2014 05:34 PM, Raymond Hettinger wrote:
On Aug 8, 2014, at 11:09 AM, Ethan Furman mailto:et...@stoneleaf.us>> wrote:
So why not apply a similar optimization to sum() for strings?
That I cannot answer -- I find the current situation with sum highly irritating.
It i
On 08/11/2014 08:50 PM, Stephen J. Turnbull wrote:
Chris Barker - NOAA Federal writes:
It seems pretty pedantic to say: we could make this work well,
but we'd rather chide you for not knowing the "proper" way to do
it.
Nobody disagrees. But backward compatibility gets in the way.
Something
On 08/14/2014 08:51 AM, Ben Hoyt wrote:
The enemy must be documented and exported, since users will encounter them.
enum == enemy? Is that you, Raymond? ;-)
ROFL! Thanks, I needed that!
:D
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.
On 08/12/2014 08:38 PM, Steven D'Aprano wrote:
[1] Technically not, since it's the comma, not the ( ), which makes a
tuple, but a lot of people don't know that and treat it as if it the
parens were compulsary.
It might as well be, because if there can be a non-tuple way to interpret the comma
On 08/13/2014 10:32 AM, Steven D'Aprano wrote:
(2) Also note that *this is already the case*, since tuples are made by
the commas, not the parentheses. E.g. this succeeds:
# Not a tuple, actually two context managers.
with open("/tmp/foo"), open("/tmp/bar", "w"):
pass
Thanks for proving m
On 08/15/2014 08:08 PM, Steven D'Aprano wrote:
On Fri, Aug 15, 2014 at 02:08:42PM -0700, Ethan Furman wrote:
On 08/13/2014 10:32 AM, Steven D'Aprano wrote:
(2) Also note that *this is already the case*, since tuples are made by
the commas, not the parentheses. E.g. this succeeds
On 08/17/2014 10:16 AM, Donald Stufft wrote:
For the record I’ve had all of the problems that Nick states and I’m
+1 on this change.
I've had many of the problems Nick states and I'm also +1.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.
On 08/17/2014 02:19 PM, Raymond Hettinger wrote:
On Aug 17, 2014, at 11:33 AM, Ethan Furman wrote:
I've had many of the problems Nick states and I'm also +1.
There are two code snippets below which were taken from the standard library.
[...]
My issues are with 'bytes&#
On 08/17/2014 04:08 PM, Nick Coghlan wrote:
I'm fine with postponing the deprecation elements indefinitely (or just
deprecating bytes(int) and leaving
bytearray(int) alone).
+1 on both pieces.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@pytho
On 08/20/2014 03:31 PM, Nick Coghlan wrote:
On 21 Aug 2014 08:19, "Greg Ewing" mailto:greg.ew...@canterbury.ac.nz>> wrote:
Antoine Pitrou wrote:
I think if you want low-level features (such as unconverted bytes paths under
POSIX), it is reasonable to point you to low-level APIs.
The prob
On 08/20/2014 05:15 PM, Nick Coghlan wrote:
On 21 August 2014 09:33, Ethan Furman wrote:
On 08/20/2014 03:31 PM, Nick Coghlan wrote:
scandir is low level (the entire os module is low level). In fact, aside
from pathlib, I'd consider pretty much every
API we have that deals with paths
On 08/29/2014 01:00 PM, M.-A. Lemburg wrote:
On 29.08.2014 21:47, Alex Gaynor wrote:
I've just submitted PEP 476, on enabling certificate validation by default for
HTTPS clients in Python. Please have a look and let me know what you think.
Thanks for the PEP. I think this is generally a good
On 08/31/2014 02:19 PM, Marko Rauhamaa wrote:
Victor Stinner :
Sorry but I don't understand your remark. What is your problem with
retrying syscall on EINTR?
The application will often want the EINTR return (exception) instead of
having the function resume on its own.
Examples?
As an ignor
On 09/03/2014 08:58 AM, R. David Murray wrote:
I'm OK with letting go of this invalid-cert issue myself, given the lack
of negative feedback Twisted got. I'll just keep my fingers crossed.
I apologize if I missed this point, but if we have the source code then it is possible to go in and dire
On 09/03/2014 10:15 AM, Alex Gaynor wrote:
Ethan Furman writes:
I apologize if I missed this point, but if we have the source code then it is
possible to go in and directly modify the application/utility to be able to
talk over https to a router with an invalid certificate? This is an option
On 09/03/2014 12:10 PM, R. David Murray wrote:
On Wed, 03 Sep 2014 10:09:36 -0700, Ethan Furman wrote:
On 09/03/2014 08:58 AM, R. David Murray wrote:
I'm OK with letting go of this invalid-cert issue myself, given the lack
of negative feedback Twisted got. I'll just keep my finge
On 09/03/2014 04:36 PM, Antoine Pitrou wrote:
On Thu, 4 Sep 2014 09:19:56 +1000
Nick Coghlan wrote:
Python is routinely updated to bugfix releases by Linux distributions
and other distribution channels, you usually have no say over what's
shipped in those updates. This is not like changing the
On 09/03/2014 05:00 PM, Ethan Furman wrote:
On 09/03/2014 04:36 PM, Antoine Pitrou wrote:
On Thu, 4 Sep 2014 09:19:56 +1000
Nick Coghlan wrote:
Python is routinely updated to bugfix releases by Linux distributions
and other distribution channels, you usually have no say over what's
sh
On 09/15/2014 03:46 PM, Mark Lawrence wrote:
On 15/09/2014 23:29, Mark Shannon wrote:
I think this is an OK forum for this question.
It isn't. ;)
If someone isn't sure if something is a bug or not, then why not ask
here before reporting it on the bug tracker?
The first stop should still
On 09/24/2014 09:11 PM, Larry Hastings wrote:
Therefore: if VC14 doesn't ship by 3.5 RC1, currently set at August 5, 2015, I
decree we have to ship 3.5 with the
previous version.
Reasonable?
Seems reasonable to me.
--
~Ethan~
___
Python-Dev mailin
With the incredibly long life span of 2.7, which bugs should we *not* fix?
For example, in http://bugs.python.org/issue22297 I mentioned one reason to not fix that bug was that the fix was not in
3.1-3.3, but 2.7 will outlive all those plus a couple more.
So, what are the current guidelines on
On 10/09/2014 03:47 PM, Jesus Cea wrote:
[] mUTF-7 support [...]
What do you think?. Could be considered for Python 3.5?.
+1
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsub
On 10/29/2014 03:09 PM, Paul Moore wrote:
On 29 October 2014 20:26, Donald Stufft wrote:
This sounds like something good for packaging.python.org
Yeah, I wondered about that. I'll work up a patch for that. But the
more I think about it, it really is trivial:
I am reminded of an interview qu
On 10/29/2014 03:46 PM, Paul Moore wrote:
On 29 October 2014 22:19, Ethan Furman wrote:
- where one should be at when one starts the compile process
I don't understand this. It's just "pip wheel foo" to build a wheel
for foo (which will be downloaded), or "
Just to be clear, this is about NotImplemented, not NotImplementedError.
tl;dr When a binary operation fails, should an exception be raised or
NotImplemented returned?
When a binary operation in Python is attempted, there are two possibilities:
- it can work
- it can't work
The main rea
On 11/03/2014 08:12 AM, R. David Murray wrote:
On Mon, 03 Nov 2014 15:05:31 +, Brett Cannon wrote:
On Mon Nov 03 2014 at 5:31:21 AM Ethan Furman wrote:
Just to be clear, this is about NotImplemented, not NotImplementedError.
tl;dr When a binary operation fails, should an exception be
Summary:
NotImplemented _should_ be used by the normal and reflected binary methods
(__lt__, __add__, __xor__, __rsub__, etc.)
NotImplemented _may_ be used by the in-place binary methods (__iadd__, __ixor__, etc.), but the in-place methods are
also free to raise an exception.
Correct?
--
~E
This list is for the development _of_ Python, not development _with_ Python.
Try asking on Python List.
(forwarding...)
On 11/04/2014 08:52 AM, Roberto Martínez wrote:
I am trying to replace dinamically the __call__ method of an object using
setattr.
Example:
$ cat testcall.py
class A:
I'm looking for real-world uses of collections.Counter, specifically to see if anyone has been surprised by, or had to
spend extra-time debugging, issues with the in-place operators.
If sufficient and/or compelling use-cases are uncovered, the behavior of
Counter may be slightly modified.
Back
On 11/05/2014 10:09 AM, MRAB wrote:
On 2014-11-05 16:33, Ethan Furman wrote:
Even worse (in my opinion) is the case of an empty Counter `and`ed with an
incompatible type:
--> c &= [1, 2, 3]
-->
No error is raised at all.
The final example, however, is odd. I think that one shoul
On 11/05/2014 10:56 AM, Raymond Hettinger wrote:
Please stop using the mailing lists as way to make an end-run around
discussions on the tracker.
http://bugs.python.org/issue22766
You said that without compelling, real-world use cases you don't like to make
changes.
The tracker has a very l
Thank you everyone for the discussion, it has been, as always, most
educational. :)
--
~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 11/08/2014 10:46 AM, Xavier Morel wrote:
On 2014-11-08, at 16:46 , Ionel Cristian Mărieș wrote:
In the current incarnation Pathlib is missing some key features I need in
my usecases. I want to contribute them but i'd like a bit of feedback on
the new api before jumping to implementation.
On 11/13/2014 11:47 AM, Steve Dower wrote:
>
> Just wondering who is regularly/occasionally using VS 2010 to work on Python?
Very occasional.
In fact, my MSDS subscription expired and I missed the last call for renewals.
:(
If it will help (and I can get a renewed subscription), I can built/t
On 11/21/2014 05:47 AM, Raymond Hettinger wrote:
>
> Also, the proposal breaks a reasonably useful pattern of calling
> next(subiterator)
> inside a generator and letting the generator terminate when the data stream
> ends.
>
> Here is an example that I have taught for years:
>
> def [...]
On 11/22/2014 06:31 AM, Nick Coghlan wrote:
>
> A particularly relevant variant of the idiom is the approach of writing
> "__iter__" directly as a generator, rather than creating a separate custom
> iterator class. In that context, the similarities between the __iter__
> implementation and the cor
On 11/22/2014 05:11 PM, Raymond Hettinger wrote:
>> On Nov 22, 2014, at 2:45 PM, Chris Angelico wrote:
>>
>> Does your middleware_generator work with just a single element,
>> yielding either one output value or none?
>
> I apologize if I didn't make the point clearly. The middleware example was
On 11/22/2014 08:53 PM, Guido van Rossum wrote:
>
> In order to save everyone's breath, I am *accepting* the proposal of PEP
> 479.
Excellent.
Chris, thank you for your time, effort, and thoroughness in championing this
PEP.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
On 11/22/2014 11:13 PM, Donald Stufft wrote:
>> On Nov 23, 2014, at 1:49 AM, Nick Coghlan wrote:
>>
>> I took the git knowledge I acquired by necessity at Red Hat and
>> figured out how to apply it to hg. All the same features are there in
>> hg, they're just switched off by default (mainly because
On 11/22/2014 12:30 PM, Raymond Hettinger wrote:
Pre-PEP 479:
---
> def middleware_generator(source_generator):
> it = source_generator()
> input_value = next(it)
> output_value = do_something_interesting(input_value)
> yield output_value
Post-PEP 479:
On 11/23/2014 08:55 AM, Brett Cannon wrote:
>
> Sure, but I would never compare our infrastructure needs to Red Hat. =) You
> also have to be conservative in order to minimize downtown and impact for
> cost reasons. As an open source project we don't have those kinds of worry;
> we just have to wor
On 11/23/2014 08:55 AM, Brett Cannon wrote:
>
> Fourth, do any core developers feel strongly about not using GitHub?
Dous GitHub support hg? If not, I am strongly opposed.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Python-De
On 11/23/2014 10:14 AM, Brett Cannon wrote:
> On Sun Nov 23 2014 at 1:08:58 PM Ethan Furman wrote:
>>
>> Dous GitHub support hg? If not, I am strongly opposed.
>>
>
> Depends on what you mean by "support". If you mean natively, then no. If
> you mean &q
1 - 100 of 1590 matches
Mail list logo
