On Wed, Nov 29, 2017 at 7:18 PM, Mario Corchero wrote:
> There were discussions about having it a function, making the constructor
> of datetime accept a string(this was strongly rejected), having a static
> function in datetime, etc... and there was no real agreement.
>
Guido has written severa
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer wrote:
> On 11/29/2017 03:26 PM, Eric V. Smith wrote:
> > I've posted a new version of PEP 557, it should soon be available at
> > https://www.python.org/dev/peps/pep-0557/.
> >
> > The only significant changes since the last version are:
> >
> > - cha
Yeah! I'm available for writing docs and testing it if needed.
Performance is not a big concern in this first version, unless you've already
written most of it. If it is a concern for others then the third-party modules
will still be available as well.
-Mike
On 2017-11-29 16:19, Paul G wr
I can write at least a pure Python implementation in the next few days, if not
a full C implementation. Shouldn't be too hard since I've got a few different
Cython implementations sitting around anyway.
On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky
wrote:
>On Wed, Nov 29, 2017 at 6
There were discussions about having it a function, making the constructor
of datetime accept a string(this was strongly rejected), having a static
funcion in datetime, etc... and there was no real agreement.
If the agreement is that we want a funcion to be able to parse it I am sure
Paul G will be
On 11/29/2017 6:51 PM, Carl Meyer wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at
https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to b
On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker wrote:
>
> indeed what is the holdup? I don't recall anyone saying it was a bad idea
> in the last discussion.
>
> Do we just need an implementation?
>
> Is the one in the Bug Report not up to snuff? If not, then what's wrong
> with it? This is just n
2017-11-12 10:24 GMT+01:00 Nick Coghlan :
> I've written a short(ish) PEP for the proposal to change the default
> warnings filters to show DeprecationWarning in __main__:
> https://www.python.org/dev/peps/pep-0565/
I understand the rationale of the PEP, but I dislike the proposed
implementation.
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
> I've posted a new version of PEP 557, it should soon be available at
> https://www.python.org/dev/peps/pep-0557/.
>
> The only significant changes since the last version are:
>
> - changing the "compare" parameter to be "order", since that more
> acc
On Wed, Nov 29, 2017 at 10:05 AM, Mike Miller
wrote:
> This thread isn't about the numerous third-party solutions that are a pip
> command away. But rather getting a minimal return parser to handle
> datetime.isoformat() into the std library.
>
> It's been needed for years,
indeed what is the
I plan to accept this on Monday if no new objections are raised.
On Nov 29, 2017 3:28 PM, "Eric V. Smith" wrote:
> I've posted a new version of PEP 557, it should soon be available at
> https://www.python.org/dev/peps/pep-0557/.
>
> The only significant changes since the last version are:
>
> -
I've posted a new version of PEP 557, it should soon be available at
https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination
Hm. For the file used for lookup, I see the point of keeping it. But in
general, I don't see the point of keeping files we no longer need -- that's
what VCS systems are for!
On Wed, Nov 29, 2017 at 2:28 PM, Serhiy Storchaka
wrote:
> 29.11.17 21:00, Guido van Rossum пише:
>
>> That sounds a bit e
On 11/29/2017 07:26 PM, Serhiy Storchaka wrote:
[...] Perhaps it is
worth to track all removals in a special file, so if later you will find
that the removed file can be useful you could restore it instead of
recreating its functionality from zero in the case if you even don't
know that simil
29.11.17 21:00, Guido van Rossum пише:
That sounds a bit excessive. Is there a recent incident that inspired
this proposal?
The concrete inspiration is issue32159 [1]. I am still not sure that
removing these scripts is needed. But there were other cases in which I
was not sure about the ratio
Hi,
Serhiy opened this thread after I removed tools for CVS and Subversion from
the master branch: two scripts and a svnmap.txt file. I removed
Misc/svnmap.txt, a mapping of Subversion commits to Mercurial commits. The
change was approved by 3 core dev, but then I was asked to restore (only)
the s
29.11.17 20:47, Ryan Gonzalez пише:
Doesn't Git make this rather easy, though?
e.g. you can find all deleted files with:
git log --diff-filter=D --summary
and find a specific file with (showing glob patterns):
git log --all --full-history -- **/thefile.*
and then show it:
git show --
or
On Nov 28, 2017 3:55 PM, "Guido van Rossum" wrote:
On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith wrote:
> Eh, numpy does use FutureWarning for changes where the same code will
> transition from doing one thing to doing something else without
> passing through a state where it raises an error
On Wed, Nov 29, 2017 at 1:47 PM, Ryan Gonzalez wrote:
> Doesn't Git make this rather easy, though?
+1.
PEP-like process for removing/renaming files is too much, in my opinion.
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
That sounds a bit excessive. Is there a recent incident that inspired this
proposal?
On Wed, Nov 29, 2017 at 10:26 AM, Serhiy Storchaka
wrote:
> After removing files from the repository they disappear from the source
> tree, and it is even hard to notice this if you don't use it regularly. It
>
Doesn't Git make this rather easy, though?
e.g. you can find all deleted files with:
git log --diff-filter=D --summary
and find a specific file with (showing glob patterns):
git log --all --full-history -- **/thefile.*
and then show it:
git show --
or restore it:
git checkout ^ --
http
After removing files from the repository they disappear from the source
tree, and it is even hard to notice this if you don't use it regularly.
It is hard to track the history of the removed file even if you know it
exact path. If you know it only approximate this is harder.
I think that any f
On 28 November 2017 at 18:38, Barry Warsaw wrote:
> On Nov 28, 2017, at 15:31, Raymond Hettinger
> wrote:
>
>> Put me down for a strong -1. The proposal would occasionally save a few
>> keystokes but comes at the expense of giving Python a more Perlish look and
>> a more arcane feel.
>
> I a
Hi,
This thread isn't about the numerous third-party solutions that are a pip
command away. But rather getting a minimal return parser to handle
datetime.isoformat() into the std library.
It's been needed for years, and hopefully someone can squeeze it into 3.7 before
its too late. (It tak
On Nov 29, 2017, at 12:40, David Mertz wrote:
> I think some syntax could be possible to only "catch" some exceptions and let
> others propagate. Maybe:
>
>val = name.strip()[4:].upper() except (AttributeError, KeyError): -1
>
> I don't really like throwing a colon in an expression though
> On Nov 29, 2017, at 12:40 PM, David Mertz wrote:
>
> I like much of the thinking in Random's approach. But I still think None
> isn't quite special enough to warrant it's own syntax.
>
> However, his '(or None: name.strip()[4:].upper())' makes me realize that what
> is being asked in all th
I like much of the thinking in Random's approach. But I still think None
isn't quite special enough to warrant it's own syntax.
However, his '(or None: name.strip()[4:].upper())' makes me realize that
what is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of
ternary expression. Ex
On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote:
>
> > I also cc python-dev to see if anybody here is strongly in favor or against
> > this inclusion.
>
> Put me down for a strong -1. The proposal would occasionally save a few
> keystokes but comes at the expense of giving Python a mor
> On Nov 19, 2017, at 8:40 AM, Nathaniel Smith wrote:
>
> We have been using DeprecationWarning for changes where code will
> transition from working -> raising an error, and that *is* based on
> the Official Recommendation to hide those by default whenever
> possible. We've been doing this for
On 29 November 2017 at 06:17, Guido van Rossum wrote:
> Please, not for 3.7. I think it will be very difficult to get consensus
> about this, and I personally feel something like +/- zero about it --
> sometimes I think it makes sense, sometimes I think we're jumping the shark
> here.
I've marked
On 11/28/2017 8:31 PM, Eric V. Smith wrote:
On 11/28/2017 4:14 PM, Guido van Rossum wrote:
Hm. Maybe for the ordering comparisons we could defer to the class
with the longest list of fields, as long as there's a subtype
relationship? That way bb would be equivalent, and both would
use C.__gt__
28.11.17 22:31, Raymond Hettinger пише:
I also cc python-dev to see if anybody here is strongly in favor or against
this inclusion.
Put me down for a strong -1. The proposal would occasionally save a few
keystokes but comes at the expense of giving Python a more Perlish look and a
more arc
32 matches
Mail list logo
