Re: [Python-Dev] Issue?

I wrote Python's sort, so I may know something about it ;-) To my eyes, no, there's not "an issue" here, but a full explanation would be very involved. For some sorting algorithms, it's possible to guarantee a redundant comparison is never made. For example, a pure insertion sort. But Python's

Re: [Python-Dev] Issue?

python used the "timsort" sorting routine: https://en.wikipedia.org/wiki/Timsort So you can look at that and confirm that this is correct behaviour (I'm betting it is :-) But in general, sorting is O(n log(n)) -- there are going to be more than n comparisons. If comparing is slow, you want to

Re: [Python-Dev] Issue?

On Wed, Aug 22, 2018 at 06:40:42PM +0800, 楼晓峰 wrote: > Why compare twice? This is not a mailing list for asking for help with your own code. You can try this list instead: https://mail.python.org/mailman/listinfo/python-list -- Steve ___

Re: [Python-Dev] Issue 32933

Hey Tony, You can raise a PR and then start working on writing a test case of it. People would then be able to see what exactly you've done and suggest changes if need be. Let me know if you've any more questions. On Sat, Mar 3, 2018 at 11:24 PM, TonyFlury via Python-Dev

Re: [Python-Dev] Issue #21071: change struct.Struct.format type from bytes to str

2017-06-16 10:40 GMT+02:00 Nick Coghlan : > As long as it's noted in the "Porting to Python 3.7" section of the > 3.7 What's New guide, this seems like a sensible change to me. Yes, the change is already documented there: https://github.com/python/cpython/pull/845/files

Re: [Python-Dev] Issue #21071: change struct.Struct.format type from bytes to str

On 16 June 2017 at 14:19, Serhiy Storchaka wrote: > 27.03.17 15:12, Victor Stinner пише: >> >> I would like to change struct.Struct.format type from bytes to str. I >> don't expect that anyone uses this attribute, and struct.Struct() >> constructor accepts both bytes and str.

Re: [Python-Dev] Issue #21071: change struct.Struct.format type from bytes to str

27.03.17 15:12, Victor Stinner пише: I would like to change struct.Struct.format type from bytes to str. I don't expect that anyone uses this attribute, and struct.Struct() constructor accepts both bytes and str. http://bugs.python.org/issue21071 It's just to be convenient: more functions

Re: [Python-Dev] Issue with _thread.interrupt_main (29926)

On 29 March 2017 at 00:40, Terry Reedy wrote: > [. . .] Eryk Sun suggested a patch for Windows, (and > the possibility of using pthread_kill). Can you possibly do one for *nix? > This is out of my ballpark, but the bug (relative to console behavior) is a > nuisance. I'll try

Re: [Python-Dev] Issue with _thread.interrupt_main (29926)

Steven, thanks for verifying bug on *nix. On 3/28/2017 2:00 AM, Martin Panter wrote: On 28 March 2017 at 03:11, Steven D'Aprano wrote: On Mon, Mar 27, 2017 at 10:33:44PM -0400, Terry Reedy wrote: https://bugs.python.org/issue29926 was opened as an IDLE issue, which means

Re: [Python-Dev] Issue with _thread.interrupt_main (29926)

On 28 March 2017 at 03:11, Steven D'Aprano wrote: > On Mon, Mar 27, 2017 at 10:33:44PM -0400, Terry Reedy wrote: >> https://bugs.python.org/issue29926 was opened as an IDLE issue, which >> means that most watching the new issues list would ignore it. But I >> think it is an

Re: [Python-Dev] Issue with _thread.interrupt_main (29926)

On Mon, Mar 27, 2017 at 10:33:44PM -0400, Terry Reedy wrote: > https://bugs.python.org/issue29926 was opened as an IDLE issue, which > means that most watching the new issues list would ignore it. But I > think it is an issue with _thread.interrupt_main (which IDLE calls in > respond to ^C)

Re: [Python-Dev] Issue #23903 - stable API is incomplete

er" <victor.stin...@gmail.com> Sent: ‎12/‎21/‎2016 8:40 To: "Nathaniel Smith" <n...@pobox.com> Cc: "Steve Dower" <steve.do...@python.org>; "Serhiy Storchaka" <storch...@gmail.com>; "Python Dev" <python-dev@python.org> Su

Re: [Python-Dev] Issue #23903 - stable API is incomplete

> Sent: ‎12/‎21/‎2016 8:22 To: "Steve Dower" <steve.do...@python.org> Cc: "Serhiy Storchaka" <storch...@gmail.com>; "Victor Stinner" <victor.stin...@gmail.com>; "Python Dev" <python-dev@python.org> Subject: Re: [Python-Dev]

Re: [Python-Dev] Issue #23903 - stable API is incomplete

2016-12-21 17:21 GMT+01:00 Nathaniel Smith : > It sounds like the opt-out approach isn't working very well, and maybe an > opt-in approach should be considered instead? I recognize that the way C > headers work makes this difficult, but it seems like something needs to > change. I

Re: [Python-Dev] Issue #23903 - stable API is incomplete

On Dec 21, 2016 7:43 AM, "Steve Dower" wrote: "Ok, now why should _Py_PrintReferences() function be exported?" It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it is excluded from the headers (my list was automatically generated). It sounds like

Re: [Python-Dev] Issue #23903 - stable API is incomplete

On 21.12.16 17:41, Steve Dower wrote: "Ok, now why should _Py_PrintReferences() function be exported?" It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it is excluded from the headers (my list was automatically generated). And ideally, private functions that are

Re: [Python-Dev] Issue #23903 - stable API is incomplete

comments, or if they're new, a version check on Py_LIMITED_API. Top-posted from my Windows Phone -Original Message- From: "Victor Stinner" <victor.stin...@gmail.com> Sent: ‎12/‎21/‎2016 6:25 To: "Serhiy Storchaka" <storch...@gmail.com> Cc: "Python Dev&qu

Re: [Python-Dev] Issue #23903 - stable API is incomplete

2016-12-21 14:06 GMT+01:00 Serhiy Storchaka : >> These functions are private. Would it be possible to not export them? > > Private functions used in public macros (like _Py_NewReference) should be > exported. Ah, _Py_NewReference is used in the PyObject_INIT(op, typeobj)

Re: [Python-Dev] Issue #23903 - stable API is incomplete

On 21.12.16 11:50, Victor Stinner wrote: 2016-12-21 2:52 GMT+01:00 Steve Dower : _PyBytes_DecodeEscape _PyDebug_PrintTotalRefs _PyThreadState_Current _PyTrash_thread_deposit_object _PyTrash_thread_destroy_chain _PyUnicode_DecodeUnicodeEscape _Py_AddToAllObjects

Re: [Python-Dev] Issue #23903 - stable API is incomplete

2016-12-21 2:52 GMT+01:00 Steve Dower : > _PyBytes_DecodeEscape > _PyDebug_PrintTotalRefs > _PyThreadState_Current > _PyTrash_thread_deposit_object > _PyTrash_thread_destroy_chain > _PyUnicode_DecodeUnicodeEscape > _Py_AddToAllObjects > _Py_ForgetReference > _Py_GetRefTotal

Re: [Python-Dev] Issue #23903 - stable API is incomplete

I should also point out that when 3.6.0 releases, all of these will already be in the stable API for other platforms. I'm not going to take a stance on whether we can break it there between 3.6.0 and 3.6.1, but it may already be too late to remove any. Top-posted from my Windows Phone

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

Victor Stinner gmail.com> writes: > > Hi, > > I changed the Python compiler to ignore any kind "constant > expressions", whereas it only ignored strings and integers before: > http://bugs.python.org/issue26204 > > The compiler now also emits a SyntaxWarning on such case. IMHO the > warning

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

2016-02-09 10:57 GMT+01:00 Joseph Martinot-Lagarde : > I frequently use 1/0 as a quick break in a script or a program (it's even > more useful with post-mortem debugging). Would it be considered as a > constant and ignored instead of raising a ZeroDivisionError ? "self.x -

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

On 02/09/2016 10:57 AM, Joseph Martinot-Lagarde wrote: > Victor Stinner gmail.com> writes: > >> >> Hi, >> >> I changed the Python compiler to ignore any kind "constant >> expressions", whereas it only ignored strings and integers before: >> http://bugs.python.org/issue26204 >> >> The compiler

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

Hello, Le 08/02/2016 20:13, Guido van Rossum a écrit : On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner wrote: I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before:

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

On Tuesday, February 9, 2016 8:14 AM, Michel Desmoulin wrote: > I give regular Python trainings and I see similar errors regularly such as: > > - not returning something; > - using something without putting the result back in a variable. > > However, these are

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

On 2016-02-08 8:02 PM, Steven D'Aprano wrote: On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote: On 2016-02-08 5:19 PM, Terry Reedy wrote: On 2/8/2016 4:51 PM, Victor Stinner wrote: 2016-02-08 22:28 GMT+01:00 Alexander Walters : What incantation do

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

On Tue, Feb 9, 2016 at 7:34 AM, Guido van Rossum wrote: > On Mon, Feb 8, 2016 at 11:51 AM, Victor Stinner > wrote: >> Le 8 févr. 2016 8:14 PM, "Guido van Rossum" a écrit : >>> Hum. I'm not excited by this idea. It is not bad syntax.

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

On Tue, Feb 9, 2016 at 12:41 PM, MRAB wrote: > On 2016-02-09 00:53, Guido van Rossum wrote: >> >> The warning for 'assert (cond, msg)' was specifically put in because >> this is a nasty trap. It's *always* a mistaken attempt to write >> 'assert cond, msg' -- usually in

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

On Mon, Feb 8, 2016 at 5:41 PM, MRAB wrote: > On 2016-02-09 00:53, Guido van Rossum wrote: >> >> The warning for 'assert (cond, msg)' was specifically put in because >> this is a nasty trap. It's *always* a mistaken attempt to write >> 'assert cond, msg' -- usually in

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

On 2016-02-09 00:53, Guido van Rossum wrote: The warning for 'assert (cond, msg)' was specifically put in because this is a nasty trap. It's *always* a mistaken attempt to write 'assert cond, msg' -- usually in an attempt to break a long line without using a backslash. I'd actually consider

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

Personally I don't think it's worth the churn. On Mon, Feb 8, 2016 at 5:49 PM, Chris Angelico wrote: > On Tue, Feb 9, 2016 at 12:41 PM, MRAB wrote: >> On 2016-02-09 00:53, Guido van Rossum wrote: >>> >>> The warning for 'assert (cond, msg)' was

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

>> New behaviour: >> >> haypo@smithers$ ./python >> Python 3.6.0a0 (default:759a975e1230, Feb 8 2016, 18:21:23) > def f(): >> ... False >> ... Ok, I see in your case there's no return :-) ___ Python-Dev mailing list Python-Dev@python.org

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

Hi, On 02/08/2016 06:44 PM, Victor Stinner wrote: > Hi, > > I changed the Python compiler to ignore any kind "constant > expressions", whereas it only ignored strings and integers before: > http://bugs.python.org/issue26204 > > The compiler now also emits a SyntaxWarning on such case. IMHO the

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

On 02/08/2016 10:00 AM, francismb wrote: > On 02/08/2016 06:44 PM, Victor Stinner wrote: >> I changed the Python compiler to ignore any kind "constant >> expressions", whereas it only ignored strings and integers before: >> http://bugs.python.org/issue26204 >> >> The compiler now also emits a

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

On 02/08/2016 09:44 AM, Victor Stinner wrote: > Are you ok with the new warning? +1 -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

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

On Mon, Feb 8, 2016 at 9:44 AM Victor Stinner wrote: > Hi, > > I changed the Python compiler to ignore any kind "constant > expressions", whereas it only ignored strings and integers before: > http://bugs.python.org/issue26204 > > The compiler now also emits a

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

On Mon, Feb 8, 2016 at 11:51 AM, Victor Stinner wrote: > Le 8 févr. 2016 8:14 PM, "Guido van Rossum" a écrit : >> Hum. I'm not excited by this idea. It is not bad syntax. > > Do you see an use case for "constant statements" other than strings and >

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

On Tue, Feb 9, 2016 at 8:20 AM, Victor Stinner wrote: > Le 8 févr. 2016 9:34 PM, "Guido van Rossum" a écrit : >> If you want to do linter integration that should probably be >> integrated with the user's editor, like it is in PyCharm, and IIUC >>

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

On 02/08/2016 10:15 AM, Ethan Furman wrote: On 02/08/2016 09:44 AM, Victor Stinner wrote: > Are you ok with the new warning? +1 Changing my vote: -1 on the warning +0 on simply removing the unused constant -- ~Ethan~ ___ Python-Dev mailing list

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

Le 8 févr. 2016 9:10 PM, "Alexander Walters" a écrit : > > I am not keen on a SyntaxWarning. Either something is python syntax, or it is not. Oh I forgot to mention that Python already emits SyntaxWarning, on "assert True" for example. Victor

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

On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner wrote: > I changed the Python compiler to ignore any kind "constant > expressions", whereas it only ignored strings and integers before: > http://bugs.python.org/issue26204 > > The compiler now also emits a SyntaxWarning on

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

> On Feb 8, 2016, at 11:13, Guido van Rossum wrote: > >> On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner >> wrote: >> I changed the Python compiler to ignore any kind "constant >> expressions", whereas it only ignored strings and integers before: >>

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

Le 8 févr. 2016 9:34 PM, "Guido van Rossum" a écrit : > If you want to do linter integration that should probably be > integrated with the user's editor, like it is in PyCharm, and IIUC > people can do this in e.g. Emacs, Sublime or Vim as well. Leave the > interpreter alone.

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

On Mon, Feb 8, 2016 at 1:20 PM, Victor Stinner wrote: > Le 8 févr. 2016 9:34 PM, "Guido van Rossum" a écrit : >> If you want to do linter integration that should probably be >> integrated with the user's editor, like it is in PyCharm, and IIUC >>

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

What incantation do you need to do to make that behavior apparent? tritium@gesa:~$ python3.5 -W all Python 3.5.1 (default, Dec 18 2015, 02:15:10) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. Jedi is not installed, falling back to readline >>> assert

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

On Tue, Feb 9, 2016 at 8:41 AM, Alexander Walters wrote: > > > 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

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

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

Le 8 févr. 2016 8:14 PM, "Guido van Rossum" a écrit : > Hum. I'm not excited by this idea. It is not bad syntax. Do you see an use case for "constant statements" other than strings and ellipsis? Such statement does nothing. Previously the compiler emited LOAD_CONST+POP_TOP.

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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On 2016-02-08 5:19 PM, Terry Reedy wrote: On 2/8/2016 4:51 PM, Victor Stinner wrote: 2016-02-08 22:28 GMT+01:00 Alexander Walters : What incantation do you need to do to make that behavior apparent? I didn't know. I just checked. It's assert used with a non-empty

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

On Tue, Feb 9, 2016 at 8:51 AM, Victor Stinner wrote: > 2016-02-08 22:28 GMT+01:00 Alexander Walters : >> What incantation do you need to do to make that behavior apparent? > > I didn't know. I just checked. It's assert used with a non-empty

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

On 2/8/2016 4:51 PM, Victor Stinner wrote: 2016-02-08 22:28 GMT+01:00 Alexander Walters : What incantation do you need to do to make that behavior apparent? I didn't know. I just checked. It's assert used with a non-empty tuple: assert ("tuple",) :1: SyntaxWarning:

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

2016-02-08 22:28 GMT+01:00 Alexander Walters : > What incantation do you need to do to make that behavior apparent? I didn't know. I just checked. It's assert used with a non-empty tuple: >>> assert ("tuple",) :1: SyntaxWarning: assertion is always true, perhaps remove

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

On Mon, Feb 8, 2016 at 3:48 PM, MRAB wrote: > help('assert') > > You'll see that in "assert (True,)", the tuple (an object) is the first > condition (and probably a mistake), whereas in "assert True,", the True is > the condition and the second expression (after

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

On 2016-02-08 23:21, Chris Barker wrote: On Mon, Feb 8, 2016 at 1:51 PM, Victor Stinner > wrote: I didn't know. I just checked. It's assert used with a non-empty tuple: >>> assert ("tuple",) which is more interesting with a

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

On Mon, Feb 8, 2016 at 1:51 PM, Victor Stinner wrote: > I didn't know. I just checked. It's assert used with a non-empty tuple: > > >>> assert ("tuple",) > which is more interesting with a tuple without the parentheses: t = In [*4*]: t = True, In [*5*]: t Out[*5*]:

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

The warning for 'assert (cond, msg)' was specifically put in because this is a nasty trap. It's *always* a mistaken attempt to write 'assert cond, msg' -- usually in an attempt to break a long line without using a backslash. I'd actually consider promoting it to a syntax error rather than removing

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

On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote: > > > On 2016-02-08 5:19 PM, Terry Reedy wrote: > >On 2/8/2016 4:51 PM, Victor Stinner wrote: > >>2016-02-08 22:28 GMT+01:00 Alexander Walters : > >>>What incantation do you need to do to make that behavior

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

2015-10-02 9:37 GMT+02:00 Nick Coghlan : > Spell it as "sys.implementation.debug_build" and I'm in favour. Oh, in fact, I don't have no preference between sys.debug_flag and sys.implementation.debug_flag. If I understood correctly, Serhiy would prefer

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

Speaking of other python implementations - why would you even care? (the pypy debug build has very different properties and does very different stuff for example). I would be very happy to have this clearly marked as implementation-dependent and that's why it would be cool to not be in sys (there

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

On Oct 02, 2015, at 11:46 AM, Victor Stinner wrote: >Should I write a PEP for a new field in sys.implementation? Specifically PEP 421 says that a PEP is needed if the new sys.implementation attribute is required to be defined in all implementations, i.e. it's a new required attribute. Will

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

2015-10-02 13:16 GMT+02:00 Nir Soffer : > Whats wrong with: > sysconfig.get_config_var('Py_DEBUG') > 0 Again, refer to my first message "On the Internet, I found various recipes to check if Python is compiled is debug mode. Sadly, some of them are not portable." I don't

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

Whats wrong with: >>> sysconfig.get_config_var('Py_DEBUG') 0 Nir On Fri, Oct 2, 2015 at 10:18 AM, Victor Stinner wrote: > Hi, > > I created the issue "Add sys.debug_build public variable to check if > Python was compiled in debug mode":

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

On 02.10.15 10:18, Victor Stinner wrote: I would like to add an obvious way to check if Python was compiled in debug mode, instead of having hacks/tips to check it. On the Internet, I found various recipes to check if Python is compiled is debug mode. Sadly, some of them are not portable. I

Re: [Python-Dev] Issue #25256: Add sys.debug_build?

On 2 October 2015 at 17:18, Victor Stinner wrote: > What do you think? Should we add sys.debug_build? Spell it as "sys.implementation.debug_build" and I'm in favour. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia

Re: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

On 8 July 2015 at 05:12, Barry Warsaw ba...@python.org wrote: On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote: To me, the main question is whether you are sure that your proposal is the right fix, or whether you might reasonably do something different (with the new arguments) if changes were

Re: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

On Jul 09, 2015, at 08:47 PM, Nick Coghlan wrote: That strikes me as just the kind of not-quite-as-finished-as-we-thought case that the beta cycle is designed to flush out, so the minor further enhancement sounds like a good idea to me. Cool. RDM provided some good feedback in the review, so

Re: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote: To me, the main question is whether you are sure that your proposal is the right fix, or whether you might reasonably do something different (with the new arguments) if changes were reverted for the present and you two took more time to think about

Re: [Python-Dev] Issue #15014 - SMTP AUTH initial-response (beta exception requested)

On 7/7/2015 1:52 PM, Barry Warsaw wrote: Larry and others, I'd like to bring your attention to issue #15014. This issue added arbitrary auth methods to smtplib, which is a good thing. Implicitly though, a regression was introduced w.r.t. RFC 4954's optional initial-response for the AUTH

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

Nick Coghlan schrieb am 28.05.2015 um 05:02: On 28 May 2015 at 12:51, Ned Batchelder wrote: This issue has been fixed, but a day or two late for 3.5b1. Aye, we only found out about the missing test case via feedback *on* the beta. We had never needed to worry about it before, but it turns

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

On 28 May 2015 at 14:30, Larry Hastings la...@hastings.org wrote: On 05/27/2015 07:51 PM, Ned Batchelder wrote: This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :)

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

On 2015-05-27 11:02 PM, Nick Coghlan wrote: It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :) Until your email, I hadn't fully thought through the consequences, but the bug is actually going to block a*lot* of potential testing of the beta release

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

On Wed, May 27, 2015 at 9:54 PM, Nick Coghlan ncogh...@gmail.com wrote: On 28 May 2015 at 14:30, Larry Hastings la...@hastings.org wrote: On 05/27/2015 07:51 PM, Ned Batchelder wrote: This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

On 05/27/2015 07:51 PM, Ned Batchelder wrote: This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :) http://legacy.python.org/dev/peps/pep-0478/ //arry/

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

On 05/27/2015 08:02 PM, Nick Coghlan wrote: On 28 May 2015 at 12:51, Ned Batchelder n...@nedbatchelder.com wrote: This issue has been fixed, but a day or two late for 3.5b1. Aye, we only found out about the missing test case via feedback *on* the beta. We had never needed to worry about it

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

On 28 May 2015 at 12:51, Ned Batchelder n...@nedbatchelder.com wrote: This issue has been fixed, but a day or two late for 3.5b1. Aye, we only found out about the missing test case via feedback *on* the beta. We had never needed to worry about it before, but it turns out all our extension

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

On 05/27/2015 10:35 PM, Larry Hastings wrote: Well, certainly this sounds like something that needs to go into the regression test suite. Can someone create the issue? ... and the patch? NM, the existing fix already added a test to the regression test suite. I should have read the issue

Re: [Python-Dev] Issue 22619 at bugs.python.org

http://bugs.python.org/issue22619 Possible implementation of negative limit for traceback functions I see that Serhiy Storchaka reviewed a patch. Victor ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Issue 22619 at bugs.python.org

On Tue, Jan 6, 2015 at 8:52 AM, Dmitry Kazakov jsb...@gmail.com wrote: Greetings. I'm sorry if I'm too insistent, but it's not truly rewarding to constantly improve a patch that no one appears to need. Again, I understand people are busy working and/or reviewing critical patches, but 2

Re: [Python-Dev] Issue 22619 at bugs.python.org

Thank you for pointing this out. That's what I meant when I asked to say what's wrong with it :-) I fixed the latest patch and uploaded it. On Tue, Jan 6, 2015 at 7:48 AM, Stefan Ring stefan...@gmail.com wrote: On Tue, Jan 6, 2015 at 8:52 AM, Dmitry Kazakov jsb...@gmail.com wrote: Greetings.

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

. Thanks again!! Andy -Original Message- From: Python-Dev [mailto:python-dev-bounces+ayates=hp@python.org] On Behalf Of Benjamin Peterson Sent: Tuesday, June 17, 2014 2:07 PM To: Ned Deily; python-dev@python.org Subject: Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

On 17 June 2014 17:41, Yates, Andy (CS Houston, TX) aya...@hp.com wrote: Is it possible to drop in new OpenSSL versions on Windows without rebuilding Python? If you think this is a problem you're going to have more than once, you'll want to look hard at whether it's worth using pyOpenSSL

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

Am 17.06.14 18:41, schrieb Yates, Andy (CS Houston, TX): Python Dev, Andy here. I have a Windows product based on Python and I’m getting hammered to release a version that includes the fix in OpenSSL 1.0.1h. My product is built on a Windows system using Python installed from the standard

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

Am 17.06.14 20:27, schrieb Steve Dower: You'll only need to rebuild the _ssl and _hashlib extension modules with the new OpenSSL version. The easiest way to do this is to build from source (which has already been updated for 1.0.1h if you use the externals scripts in Tools\buildbot), and you

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

...@v.loewis.de Sent: ‎6/‎18/‎2014 2:46 To: Steve Dowermailto:steve.do...@microsoft.com; Yates, Andy (CS Houston, TX)mailto:aya...@hp.com; Python-Dev@python.orgmailto:Python-Dev@python.org Subject: Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required Am 17.06.14 20:27

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

Yates, Andy (CS Houston, TX) wrote: Python Dev, Andy here. I have a Windows product based on Python and I'm getting hammered to release a version that includes the fix in OpenSSL 1.0.1h. My product is built on a Windows system using Python installed from the standard Python installer at

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

On 17.06.2014 20:27, Steve Dower wrote: Yates, Andy (CS Houston, TX) wrote: Python Dev, Andy here. I have a Windows product based on Python and I'm getting hammered to release a version that includes the fix in OpenSSL 1.0.1h. My product is built on a Windows system using Python installed

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

In article 81f84430ce0242e5bfa5b2264777d...@blupr03mb389.namprd03.prod.outlook.com , Steve Dower steve.do...@microsoft.com wrote: You'll only need to rebuild the _ssl and _hashlib extension modules with the new OpenSSL version. The easiest way to do this is to build from source (which has

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

On Tue, Jun 17, 2014, at 12:03, Ned Deily wrote: In article 81f84430ce0242e5bfa5b2264777d...@blupr03mb389.namprd03.prod.outlook.com , Steve Dower steve.do...@microsoft.com wrote: You'll only need to rebuild the _ssl and _hashlib extension modules with the new OpenSSL version. The

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

Le 17/06/2014 14:55, M.-A. Lemburg a écrit : Alternatively, you could make use of our pyOpenSSL distribution, which includes pyOpenSSL and the OpenSSL libs (also for Windows): http://www.egenix.com/products/python/pyOpenSSL/ We created this to address the problem of having to update OpenSSL

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

On 17.06.2014 22:36, Antoine Pitrou wrote: Le 17/06/2014 14:55, M.-A. Lemburg a écrit : Alternatively, you could make use of our pyOpenSSL distribution, which includes pyOpenSSL and the OpenSSL libs (also for Windows): http://www.egenix.com/products/python/pyOpenSSL/ We created this to

Re: [Python-Dev] Issue #21205: add __qualname__ to generators

2014-06-11 18:17 GMT+02:00 Antoine Pitrou anto...@python.org: Le 11/06/2014 10:28, Victor Stinner a écrit : (...) Issues describing the problem, I attached a patch implementing my ideas: http://bugs.python.org/issue21205 Would you be ok with these (minor) incompatible changes? +1 from me.

Re: [Python-Dev] Issue #21205: add __qualname__ to generators

Hello Victor, On 2014-06-11, 10:28 AM, Victor Stinner wrote: Hi, I'm working on asyncio and it's difficult to debug code because @asyncio.coroutine decorator removes the name of the function if the function is not a generator (if it doesn't use yield from). I propose to add new gi_name and

Re: [Python-Dev] Issue #21205: add __qualname__ to generators

Le 11/06/2014 10:28, Victor Stinner a écrit : Hi, I'm working on asyncio and it's difficult to debug code because @asyncio.coroutine decorator removes the name of the function if the function is not a generator (if it doesn't use yield from). I propose to add new gi_name and gi_qualname fields

Re: [Python-Dev] issue with itertools leads the crash

On 08/04/2014 17:30, MRAB wrote: On 2014-04-08 16:31, Brett Cannon wrote: Something for Python 3.5, maybe? :-) It's not going to happen in Python 2.7; that's the end of the Python 2 series, and it's getting security fixes only. According to http://legacy.python.org/dev/peps/pep-0373/ the

Re: [Python-Dev] issue with itertools leads the crash

On 2014-04-09 14:26, Mark Lawrence wrote: On 08/04/2014 17:30, MRAB wrote: On 2014-04-08 16:31, Brett Cannon wrote: Something for Python 3.5, maybe? :-) It's not going to happen in Python 2.7; that's the end of the Python 2 series, and it's getting security fixes only. According to

Re: [Python-Dev] issue with itertools leads the crash

2015!?!? I was hoping it was a tad further off...the PyPy team is going to have to start freaking out in about 12 months. On Wed, Apr 9, 2014 at 8:26 AM, Mark Lawrence breamore...@yahoo.co.ukwrote: On 08/04/2014 17:30, MRAB wrote: On 2014-04-08 16:31, Brett Cannon wrote: Something for

Re: [Python-Dev] issue with itertools leads the crash

On Wed, Apr 9, 2014 at 1:53 PM, MRAB pyt...@mrabarnett.plus.com wrote: On 2014-04-09 14:26, Mark Lawrence wrote: On 08/04/2014 17:30, MRAB wrote: On 2014-04-08 16:31, Brett Cannon wrote: Something for Python 3.5, maybe? :-) It's not going to happen in Python 2.7; that's the end of the

Re: [Python-Dev] issue with itertools leads the crash

On Wed, Apr 09, 2014 at 02:40:21PM -0400, Geoffrey Spear wrote: Of course, this raises the question of whether making slice assignment not go into an infinite loop when the programmer asks it to is a bugfix or a new feature. Definitely a new feature. Calling:

  1   2   3   4   5   6   >