Re: [Python-Dev] New Python Initialization API

> To make the API public, _PyWstrList, _PyInitError, _PyPreConfig, > _PyCoreConfig and related functions should be made public. Would you consider making _Py_UnixMain public as well? It is useful for high level embedding and not trivial for 3rd parties to reimplement.

Re: [Python-Dev] datetime.timedelta total_microseconds

> while "some_var / some_other_var" could be doing anything. "At an elementary level the division of two natural numbers is – among other possible interpretations – the process of calculating the number of times one number is contained within another one." --

Re: [Python-Dev] datetime.timedelta total_microseconds

On Fri, Feb 15, 2019 at 5:29 PM Paul Ganssle wrote: > it allows you to use non-traditional units like weeks (timedelta(days=7)) > Weeks are traditional: >>> timedelta(weeks=1) datetime.timedelta(7) :-) ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] new binary wheels PEP idea

ts the discussion on > Discourse for you). > > Cheers, > Steve > > On 19Feb2019 1341, Brett Cannon wrote: > > Unfortunately you're still posted to the wrong list, Alexander. You want > > to mail distutils-...@python.org <mailto:distutils-...@python

[Python-Dev] new binary wheels PEP idea

Hi all, I have an idea regarding Python binary wheels on non-glibc platforms, and it seems that initially I've posted it to the wrong list ([1]) Long story short, the proposal is to use platform tuples (like compiler ones) for wheel names, which will allow much broader platform support, for examp

Re: [Python-Dev] datetime.timedelta total_microseconds

On Thu, Feb 14, 2019 at 9:07 AM Paul Ganssle wrote: > I don't think it's totally unreasonable to have other total_X() methods, > where X would be days, hours, minutes and microseconds > I do. I was against adding the total_seconds() method to begin with because the same effect can be achieved wi

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

>>>>> and builtins (other than the fact that datetime is *not* a builtin, >>>>> and as such doesn't necessarily need to be categorized in this group), is >>>>> that unlike almost all other arithmetic types, *datetime* has a >>>>> sp

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

On Wed, Jan 2, 2019 at 10:18 PM Paul Ganssle wrote: > .. the original objection was that this implementation assumes that the > datetime subclass has a constructor with the same (or a sufficiently > similar) signature as datetime. > While this was used as a possible rationale for the way standard

Re: [Python-Dev] Removal of install_misc command from distutils

ture back in Python 3.7.1? If yes, should it start to emit a deprection warning? > > Did you manage to workaround the removal? If yes, maybe we can add more doc to the Porting section of What's New in Python 3.7? > > Victor > > Le jeudi 5 juillet 2018, Alexander Belopolsky < a

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 5, 2018 at 10:10 PM Tim Peters wrote: > .. > I solved the problem in my own code by using an editor that displays a > single "=" in C source as a left-arrow graphic (that's one of its > C-specific display options - again a response to how notorious this > bug-magnet is). So assignmen

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 5, 2018 at 8:28 PM Tim Peters wrote: > [Alexander Belopolsky] > > ... > > I also think that the dreadfulness of mistyping = where == is expected > > is exaggerated. > > There are a number of core devs who would be rabidly opposed to allowing > that con

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 5, 2018 at 7:47 PM Yury Selivanov wrote: > I think I tried a variation of your proposal here > https://mail.python.org/pipermail/python-dev/2018-April/152939.html > and nobody really liked it. > > Right. I now recall your proposal. I think I did not support it at the time because I w

[Python-Dev] PEP 572: Do we really need a ":" in ":="?

I wish I had more time to make my case, but with the PEP 572 pronouncement imminent, let me make an attempt to save Python from having two assignment operators. I've re-read the PEP, and honestly I am warming up to the idea of allowing a limited form of assignment in expressions. It looks like in

[Python-Dev] Removal of install_misc command from distutils

I started porting my project [1] to Python 3.7 and came across bpo-29218: "The unused distutils install_misc command has been removed." [2] Historically, the distutils package was very conservative about changes because many 3rd party packages extended it in ways unforeseen by the Python core de

Re: [Python-Dev] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

On Fri, May 4, 2018 at 11:43 AM, Steven D'Aprano wrote: > On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote: > .. > I'm not defending Ivan's initial email. His tantrum *was* annoying, > unreasonable, and unfair to those who do care about tkinter. He could > have done better. > > But *we

Re: [Python-Dev] Symmetry arguments for API expansion

On Mon, Mar 12, 2018 at 5:18 PM, Tim Peters wrote: > [Guido] >> as_integer_ratio() seems mostly cute (it has Tim Peters all >> over it), > > Nope! I had nothing to do with it. I would have been -0.5 on adding > it had I been aware at the time. > > - I expect the audience is tiny. The datet

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On Mon, Feb 26, 2018 at 7:51 PM, Guido van Rossum wrote: .. > The reason is that for people who are not Python experts there's no obvious > reason why `for VAR = EXPR` should mean one thing and `for VAR in EXPR` > should mean another. This would be particularly surprising for people exposed to Ju

Re: [Python-Dev] Unexpected bytecode difference

On Fri, Jan 19, 2018 at 7:18 PM, Victor Stinner wrote: > It seems like the EXTENDED_ARG doc wasn't updated. I've opened to update the dis module documentation. I have also found a patch (mkfu4.patch) attached to issue 27095 where EXTENDED_ARG is described as

Re: [Python-Dev] Unexpected bytecode difference

On Fri, Jan 19, 2018 at 7:01 PM, Guido van Rossum wrote: > Presumably because Python 3 switched to wordcode. Applying dis.dis() to > these code objects results in the same output. > dis.dis(c) > 0 LOAD_NAME 0 (0) > 3 RETURN_VALUE I expected these changes to be d

[Python-Dev] Unexpected bytecode difference

I have encountered the following difference between Python 3 and 2: (py3) >>> compile('xxx', '<>', 'eval').co_code b'e\x00S\x00' (py2) >>> compile('xxx', '<>', 'eval').co_code 'e\x00\x00S' Note that 'S' (the code for RETURN_VALUE) and a zero byte are swapped in Python 2 compared to Python 3. Is

Re: [Python-Dev] iso8601 parsing

> is there a strict deadline here if we want this for Python 3.7? The deadline for the new features is the date of the first beta currently scheduled for 2018-01-29, but if you can get this in before the last alpha (2018-01-08) it will be best. See PEP 537 (https://www.python.org/dev/peps/pep-053

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 5:30 PM, Chris Barker wrote: > Let's get passed the bike shedding and make this work! Sure. Submitting a pull request for would be a good start. ___ Python-Dev mailing list Python-Dev@python

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 5:30 PM, Steven D'Aprano wrote: > Maybe I'm just being slow today, but I don't see how you can write > "generic code" to convert text to int/float/complex/Fraction, but not > times. The only difference is that instead of calling the type directly, > you call the appropriate

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters wrote: > Why make parsing ISO time special? It's not the ISO format per se that is special, but parsing of str(x). For all numeric types, int, float, complex and even fractions.Fraction, we have a roundtrip invariant T(str(x)) == x. Datetime types ar

Re: [Python-Dev] iso8601 parsing

> On Oct 25, 2017, at 11:45 AM, Alex Walters wrote: > > it means > the type of the first argument changes the semantic meaning of subsequent > arguments, and that just adds a level of confusion to any api. No, it does not. Passing a string a the first of three arguments will still be a type e

Re: [Python-Dev] iso8601 parsing

On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker wrote: > On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan wrote: >> > can anyone argue that it's not a good idea for datetime ot > be able to read the iso format it puts out? No, but the last time I suggested that that datetime types should satisfy the s

Re: [Python-Dev] for...else

On Mon, Jul 24, 2017 at 12:23 PM, Ben Hoyt wrote: > .. I found a kind of mnemonic to help me remember when the > "else" part happens: I think of it not as "for ... else" but as "break ... > else" -- saying it this way makes it clear to me that the break goes with > the else. "If this condition ins

Re: [Python-Dev] Impact of Namedtuple on startup time

On Mon, Jul 17, 2017 at 8:16 PM, Barry Warsaw wrote: > .. > > class Foo(NamedTuple, fields = 'x,y,z'): > > ... > > > > Then the name is explicit and you get to add methods > > etc. if you want. > > Yes, I like how that reads. > > I would prefer class Foo(metaclass=namedtuple, fields = 'x

Re: [Python-Dev] Impact of Namedtuple on startup time

On Mon, Jul 17, 2017 at 6:27 PM, Greg Ewing wrote: > > > Maybe a metaclass could be used to make something > like this possible: > > >class Foo(NamedTuple, fields = 'x,y,z'): > ... > > If you think of it, collection.namedtuple *is* a metaclass. A simple wrapper will make it usable as su

Re: [Python-Dev] Fwd: Re: Enum conversions in the stdlib

> I strongly prefer numeric order for signals. > > --Guido (mobile) +1 Numerical values of UNIX signals are often more widely known than their names. For example, every UNIX user knows what signal 9 does. ___ Python-Dev mailing list Python-Dev@pyth

Re: [Python-Dev] GDB macros in Misc/gdbinit are broken

On Tue, Feb 28, 2017 at 3:33 AM, Victor Stinner wrote: > > Alexander, Skip: Oh, which kind of issues do you have with > python-gdb.py? It doesn't work? You are unable to dump some data? First, I had to rename python-gdb.py to python3.6-gdb.py to make it load. Then running backt

Re: [Python-Dev] GDB macros in Misc/gdbinit are broken

On Mon, Feb 27, 2017 at 7:34 PM, Victor Stinner wrote: > Does someone still need gdbinit macros for gdb without python binding? > I find them useful. I've never had success with python-gdb.py. ___ Python-Dev mailing list Python-Dev@python.org https://

[Python-Dev] GDB macros in Misc/gdbinit are broken

I have opened an issue on b.p.o., [1] but I wonder whether Misc/gdbinit is still supported in 3.6. [1]: http://bugs.python.org/issue29673 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] "format" builtin function, docstring improvement

On Thu, Feb 9, 2017 at 1:18 PM, Hugo PROD HOMME wrote: > > I have made a template of the docstring to begin with, that I send as an attached file, but I am not familiar with docstring format. Please open an issue at bugs.python.org. We did something similar in issue #9650, [1] so I think this wi

Re: [Python-Dev] Why is PyDateTimeAPI not initialized by datetime module import?

On Thu, Jan 26, 2017 at 11:00 AM, Skip Montanaro wrote: > I just got burned (wasted a good day or so) by the fact that PyDateTimeAPI > wasn't initialized. The datetime.rst doc states (emphasis mine): > > Before using any of these functions, the header file :file:`datetime.h` > must be included in

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

On Fri, Jan 6, 2017 at 4:43 PM, Serhiy Storchaka wrote: > Compare these two calls: >> >> from array import array > bytes(array('h', [1, 2, 3])) > b'\x01\x00\x02\x00\x03\x00' >> >> and >> >> bytes(array('f', [1, 2, 3])) > b'\x00\x00\x80?\x00\x00\x00@\x00\x00@@' >> > > I don't

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

On Thu, Jan 5, 2017 at 5:54 PM, Serhiy Storchaka wrote: > On 05.01.17 22:37, Alexander Belopolsky wrote: > >> I propose the following: >> >> 1. For 3.6, restore and document 3.5 behavior. Recommend that 3rd party >> types that are both integer-like and b

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

On Wed, Oct 12, 2016 at 12:08 AM, INADA Naoki wrote: > > Now I'm sure about bytes.frombuffer() is worth enough. I would like to revive this thread (taking a liberty to shorten the subject line.) The issue of how the bytes(x) constructor should behave when given objects of various types have come

Re: [Python-Dev] Missing PY_ prefixes in structmember.h

On Mon, Oct 3, 2016 at 1:11 PM, Skip Montanaro wrote: > Why didn't these flags > (and the T_* flags in structmember.h) get swept up in all the hubbub > around the grand renaming. > Note that structmember.h is semi-private - it is not included in Python.h. See discussion at

Re: [Python-Dev] C99

On Sat, Aug 6, 2016 at 5:55 PM, Sturla Molden wrote: > Either they install Xcode or they > don't get to build anything. I always thought "Command Line Tools" would be enough. https://developer.apple.com/library/ios/technotes/tn2339/_index.html#//apple_ref/doc/uid/DTS40014588-CH1-WHAT_IS_THE_COMM

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, Aug 4, 2016 at 7:12 PM, Larry Hastings wrote: > C extension functions get the module passed in automatically, but this is > done internally and from the Python level you can't see it. Always something new to learn! This was not so in Python 2.x - self was passed as NULL to the C module

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, Aug 4, 2016 at 7:00 PM, Brett Cannon wrote: >> >>> os.rename.__text_signature__ >> '($module, /, src, dst, *, src_dir_fd=None, dst_dir_fd=None)' >> >> ? >> >> What does the "$module, /," part mean? > > > Don't remember what the $module means but the / means positional-only > arguments. No

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, Aug 4, 2016 at 2:19 PM, Larry Hastings wrote: > AFAIK the Clinic DSL can handle all of Python's C extensions. I have no > plans to "revise the whole approach"; if someone else does I haven't heard > about it. I was just wondering that with so much effort to bring typing to the mainstre

Re: [Python-Dev] Method signatures in the datetime module documentation

On Wed, Aug 3, 2016 at 10:41 PM, Martin Panter wrote: > If replace() actually supported these keywords all along, then I am happy > with this proposal. > With the obvious exception of "fold", it did at least since Python 3.0 (and likely since 2.x where x is 5 ± 1.) > There are a few bug reports

[Python-Dev] Status of the Argument Clinic DSL

What is the current status of the Argument Clinic DSL? The clinic preprocessor was released [1] with Python 3.4 with a promise [2] "that signature metadata for programmatic introspection will be added to additional callables implemented in C as part of Python 3.4 maintenance releases." We are now

Re: [Python-Dev] Method signatures in the datetime module documentation

On Fri, Jul 29, 2016 at 12:55 PM, Alexander Belopolsky wrote: > > How should I present the signature of the new replace method in the > documentation? Having not seeing any replies, let me make a proposal: datetime.replace(hour=self.hour, minute=self.minute, second=self.second, mi

[Python-Dev] Method signatures in the datetime module documentation

I have started [1] writing documentation for the new PEP 495 (Local Time Disambiguation) features and ran into the following problem. The current documentation is rather inconsistent in presenting the method signatures. For example: date.replace(year, month, day) [2], but datetime.replace([year[

Re: [Python-Dev] PEP 467: next round

On Mon, Jul 18, 2016 at 6:00 PM, Ethan Furman wrote: > bytes.fromsize() sounds good to me, thanks for brainstorming that one for > me. > +1 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscrib

Re: [Python-Dev] PEP 467: next round

On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble wrote: > full(), despite its use in numpy, is also unintuitive to me (my first > thought is that it would indicate whether an object has room for more > entries). > > Perhaps bytes.fillsize? > I wouldn't want to see bytes.full() either. Maybe byte

Re: [Python-Dev] PEP 467: next round

On Mon, Jul 18, 2016 at 4:17 PM, Ethan Furman wrote: > - 'bytes.zeros' renamed to 'bytes.size', with option byte filler > (defaults to b'\x00') > Seriously? You went from a numpy-friendly feature to something rather numpy-hostile. In numpy, ndarray.size is an attribute that returns the number

Re: [Python-Dev] Status of Python 3.6 PEPs?

On Tue, Jul 12, 2016 at 4:26 AM, Victor Stinner wrote: > > "PEP 495 -- Local Time Disambiguation" > https://www.python.org/dev/peps/pep-0495/ > => accepted > > Alexander Belopolsky asked for a review of the implementation: > https://mail.python.org/pipermai

Re: [Python-Dev] PEP 495 implementation

n for now. I will try to get the documentation patch ready before the beta, but I don't want to delay checking in the code. On Mon, Mar 21, 2016 at 10:34 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > Dear All, > > I am getting close to completing P

Re: [Python-Dev] obmalloc mmap/munmap thrashing

...is that a typo for 2.7.11? On 4/21/2016 17:44, Neil Schemenauer wrote: I was running Python 2.4.11 under strace and I noticed some odd looking system calls: mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9848681000 munmap(0x7f9848681000, 262144) =

Re: [Python-Dev] pathlib - current status of discussions

On 4/13/2016 13:49, Ethan Furman wrote: Number 3: it allows bytes, but only when told it's okay to do so. Having code get a bytes object when one is not expected is not a headache we need to inflict on anyone. This is an artifact of the other needless restrictions I said I wouldn't rant abou

Re: [Python-Dev] pathlib - current status of discussions

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 instead goes with the allow_bytes approach I originally

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 4/12/2016 12:14, Sven R. Kunze wrote: I cannot remember us using another datetime library. So, I don't value this "advantage" as much as you do. They exist, and there are many cases where you would use a datetime library other than datetime for various reasons (integration in third party s

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

solution. I think this thread can safely be sunset. On 4/11/2016 17:04, 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

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

That is great news. I just couldn't see it myself in the threads On 4/11/2016 16:51, Ethan Furman wrote: If there is headway being made, I do not see it. It's being made, and I dare say we are close to the end. ___ Python-Dev mailing list Python-

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

to implement one of them? If not, we should consider either dropping the matter or dropping the module. On 4/11/2016 16:48, Sven R. Kunze wrote: On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting

[Python-Dev] Maybe, just maybe, pathlib doesn't belong.

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 use, if that protocol should support bytes, how

Re: [Python-Dev] Defining a path protocol

On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon wrote: > +1 for __path__, +0 for __fspath__ (I don't know how widespread the notion > that "fs" means "file system" is). Same here. In the good old days, "fs" stood for a "Font Server." And in even older (and better?) days, FS was a "Field Separato

Re: [Python-Dev] When should pathlib stop being provisional?

On 4/5/2016 22:44, Nick Coghlan wrote: Option 4: define a rich-object-to-text path serialisation convention, as paths are not conceptually the same as arbitrary strings Just as a nit to pick, it is perfectly acceptable for hypothetical path objects to raise when someone tries to shoehorn them in

Re: [Python-Dev] When should pathlib stop being provisional?

On 4/5/2016 18:55, Guido van Rossum wrote: My last/only comment in the discussion was about there possibly being a dichotomy between people who use Python for scripting and those who use it to write more substantial programs (I'm trying not to judge one group more important than another -- I'm

Re: [Python-Dev] Counting references to Py_None

On Mon, Mar 21, 2016 at 5:56 PM, Tim Peters wrote: > I've seen this trigger, > from C code that had no idea it was playing with None, but just had > general refcounting errors. So this does serve a debugging purpose, > although rarely > You probably have a better refcounting sense that I do, bu

Re: [Python-Dev] Very old git mirror under github user "python-git"

Can we even ask github to pull it down and reasonably expect them to comply? Their entire model is built on everyone forking everyone else. On 2/27/2016 06:25, Mathieu Dupuy wrote: Ahah. Obtaining his electronic coordinates like email to gently ask him to pull it down by himself (otherwise we

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

that would be a good intermediate solution if it’s possible. [1]: https://www.microsoft.com/en-us/download/details.aspx?id=49983 – Chris On February 27, 2016 at 4:36:54 PM, Alexander Walters (tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com>) wrote: The 9 gig initial download

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

The 9 gig initial download is not the only problem. Visual studio is very bandwidth hungry in day to day operations (between polling websites and vcs remotes, near constant updating, integration with the VS web service, etc.). You can of course shut all of that off, but it's a pain. It's my

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

2016 at 1:10 PM, Alexander Walters wrote: Ok, fine. Bring a windows build bot online. And also take on the support burden of guiding people to which version of which compiler you use for each of the currently supported python versions. And go ahead and write the pep to change how wheel distribu

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

both visual studio and mingw. That is, there probably should be two builds on windows, since there's no clear consensus about which to use. I certainly prefer mingw over visual studio - and I have adequate bandwidth for either. On Fri, Feb 26, 2016 at 9:55 AM, Alexander Walters wrote

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

No. Visual Studio is a solid compiler suit, mingw is a jenky mess, especially when you try and move to 64bit (where I don't think there is one true version of mingw). I'm sorry that Visual Studio makes it very hard for you to contribute, but changing THE compiler of the distribution from the

[Python-Dev] Thank you.

I don't know if it is appropriate for this list, or not. I don't exactly care. As much as I might disagree with some of you... Thank you. Your work on Python has made a notable difference in how happy my life is. ___ Python-Dev mailing list Python-D

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On 2/8/2016 16:37, John Mark Vandenberg wrote: fwiw, pyflakes doesnt detect this. I've created a bug for that https://bugs.launchpad.net/pyflakes/+bug/1543246 Flake8 does, so it might be in the ... poorly named ... pep8 checker. ___ Python-Dev mai

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

led, falling back to readline >>> assert True >>> On 2/8/2016 16:23, Victor Stinner wrote: Le 8 févr. 2016 9:10 PM, "Alexander Walters" <mailto:tritium-l...@sdamon.com>> a écrit : > > I am not keen on a SyntaxWarning. Either something is python syn

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

I am not keen on a SyntaxWarning. Either something is python syntax, or it is not. This warning catches something linters have been catching for ages. I really don't see the value in adding this, and can see it causing more confusion than it solves. In the #python irc channel, we see quite

Re: [Python-Dev] HackIllinois 2016 + Python

Hello. You might want to post this in the psf-community list too. There are a lot of open source developers in the community they are not working directly on CPython (what this list is about). On 2/8/2016 12:19, Kevin Hong wrote: Hi all! My name is Kevin and I am a staff member of HackIllino

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

On 2/8/2016 12:02, Brett Cannon wrote: If Unicode string don't work in Python 2 then what is Python 2/3 to do as a cross-platform solution if we completely remove bytes support in Python 3? Wouldn't that mean there is no common type between Python 2 & 3 that one can use which will work wit

Re: [Python-Dev] More optimisation ideas

On 2/5/2016 12:27, Emile van Sebille wrote: On 2/1/2016 9:20 AM, Ethan Furman wrote: On 02/01/2016 08:40 AM, R. David Murray wrote: On the other hand, if the distros go the way Nick has (I think) been advocating, and have a separate 'system python for system scripts' that is independent of

Re: [Python-Dev] Python environment registration in the Windows Registry

do not include all of pywin32, and wxpython) and perhaps more. On 2/3/2016 14:32, Matthew Einhorn wrote: On Wed, Feb 3, 2016 at 3:15 AM, Alexander Walters mailto:tritium-l...@sdamon.com>> wrote: ...just when I thought I have solved the registry headaches I have been dealin

Re: [Python-Dev] Python environment registration in the Windows Registry

On 2/3/2016 11:17, Steve Dower wrote: I know for PTVS manually adding a python environment to visual studio is trivial - you fill in three locations, and its done. Just today I added a python environment to my system that was not autodetected. It took under a minute and almost no effort to ad

Re: [Python-Dev] Python environment registration in the Windows Registry

...just when I thought I have solved the registry headaches I have been dealing with... I am not saying this proposal will make the registry situation worse, but it may break my solution to the headaches Python's registry use causes with some non-standard module installers (and even the standa

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/19/2016 02:21, Larry Hastings wrote: On 01/18/2016 08:40 PM, Alexander Walters wrote: I am not a core developer, but I just kind of feel its hypocritical to oppose always using brackets for the development of *python* CPython isn't written in Python, it's written in C. S

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/19/2016 01:04, Glenn Linderman wrote: On 1/18/2016 9:16 PM, Greg Ewing wrote: Alexander Walters wrote: I am not a core developer, but I just kind of feel its hypocritical to oppose always using brackets for the development of *python* If we were being *really* pythonic, we would write

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/19/2016 00:09, Greg Ewing wrote: Alexander Walters wrote: When someone trying to make this argument in #python for Python code... the response is newlines are free. Well, I disagree. I very rarely put blank lines in a function in any language, because it makes it hard to scan the code

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/18/2016 23:27, Greg Ewing wrote: Brett Cannon wrote: For me, I don't see how:: if (x != 10) return NULL; do_some_more(); is any clearer or more readable than:: if (x != 10) { return NULL; } do_some_more(); Maybe not for that piece of code on its own, but the version

Re: [Python-Dev] Building with VS2015

This is a mailing list for the development of python itself, not support for building it. That said... 3.4 uses visual studio 2010, for starters. 3.5 uses 2015. It also looks like you have a lot of missing dependencies. On 1/12/2016 21:55, Eddy Quicksall wrote: I downloaded https://www.pyt

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

On Sun, Dec 20, 2015 at 10:25 PM, Tim Peters wrote: > For > > >>> print(timedelta(minutes=-1)) > > I'd like to see: > > -00:01:00 > > But I wouldn't change repr() - the internal representation is fully > documented, and it's appropriate for repr() to reflect documented > internals as directly as

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

On Sun, Dec 20, 2015 at 9:00 PM, Guido van Rossum wrote: > but I would really like to see a change in the repr of negative timedeltas: >> >> >>> timedelta(minutes=-1) >> datetime.timedelta(-1, 86340) >> >> And str() is not much better: >> >> >>> print(timedelta(minutes=-1)) >> -1 day, 23:59:00 >>

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote: > > A helpful trivia: a year is approximately π times 10 million seconds. > > Sadly doesn't help here, as the timedelta for a number of years looks like > this: > > >>> datetime.timedelta(days=365*11) > datetime.timedelta(4015) > > The origin

Re: [Python-Dev] Asynchronous context manager in a typical network server

On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum wrote: > >> It's 11 days. Which is pretty reasonable server uptime. >> > > Oops, blame the repr() of datetime.timedelta. I'm sorry I so rashly > thought I could do better than the OP. > A helpful trivia: a year is approximately π times 10 million

[Python-Dev] collections.Counter __add__ implementation quirk

collections.Counter.__add__ as a bit of a quirk. Counters allow for negative numbers. You can subtract from a counter into the negative no problem. However, if you have a counter with a negative value and add it to another counter, and if that value, after addition, would still be negative..

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

Have you ever used a command line application that --accepted --Boolean --flags? Have you ever found one that required the flags to be in order? You remember how much you hated that application for being so arbitrary about the input? That is exactly how I feel about the order mattering for

Re: [Python-Dev] PEP acceptance and SIGs

On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft wrote: > > I don’t see any requirement to post PEPs to python-dev if they have a Discussions-To header in PEP 1. When I faced a similar situation with PEP 495, Guido's advise was "I think that a courtesy message to python-dev is appropriate, with a

[Python-Dev] PEP acceptance and SIGs

It has been my understanding that some PEPs may be discussed on specialized mailings lists, but a notice would be given on python-dev prior to any acceptance. I have recently received a notification that since PEP 470 has been accepted, I can no longer use external hosting for one of the packages

Re: [Python-Dev] Committing a bug fix

On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy wrote: > Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6, That's exactly what I did at fist, but apparently while I was doing this, another commit was pushed to all three branches. To recover, I did a series of hg update 3.x; hg

Re: [Python-Dev] Committing a bug fix

On Sun, Sep 27, 2015 at 9:12 PM, R. David Murray wrote: > .. > > 3.4, 3.5, and default. > > Thanks. Maybe you can help me to make hg cooperate. I made commits to 3.4, 3.5, and default and tried to push, but hg complains: remote has heads on branch '3.4' that are not known locally: 46aaff5e894

[Python-Dev] Committing a bug fix

Can someone remind me which branches regular (non-security) bug fixes go to these days? See for context. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe

Re: [Python-Dev] PEP 495 accepted

> > [Tim Peters] > > > > > Guido's reply gave a clearer invariant: > > > > dt.timestamp() == > > dt.astimezone(utc).timestamp() == > > dt.astimezone().timestamp() > > [ Nick Coghlan] > Might it be worth mentioning Guido's invariant in the section of the PEP > about the timestamp method

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 4:14 PM, Nathaniel Smith wrote: > Is there a good argument against at least deprecating inequality > comparisons and subtraction between mixed timezone datetimes? That's a wrong question. The right question is: "Is current behavior sufficiently broken to justify a backw

  1   2   3   4   5   6   7   8   >