Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

On 20/02/2019 18:58, Victor Stinner wrote: > If Python 3.4 was the current version when a bug was reported, I would > expect the version field of the bug set to Python 3.4. Maybe the bug > has been fixed in the meanwhile, maybe not. Closing all bugs affected > to 3.4 is a risk of loosing useful inf

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

Hi, If Python 3.4 was the current version when a bug was reported, I would expect the version field of the bug set to Python 3.4. Maybe the bug has been fixed in the meanwhile, maybe not. Closing all bugs affected to 3.4 is a risk of loosing useful information on real bugs: closed bugs are ignored

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

Hi Steve, I reply on the mailing list On 02/20, Steve Dower wrote: It'll make same noise, sure, but if we schedule a bulk close of issues that have not been touched since 3.6 was released then at least it'll be easy to "mark all as read". And searching for current issues will become easier. As

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

I am against a mass changing the status of issue, since this will generate an enormous amount of noise (to me at least). But you are free to update issues one by one if you can to do some progress with them. Sure, I don't want to update them massively, just one by one. But I prefer to ask befor

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

20.02.19 17:01, Stephane Wirtel пише: As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues 3.5: 1901 issues But some issues are not related to the security. Could we update these issue

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

On 20Feb.2019 0711, Stephane Wirtel wrote: > After discussion with Victor, my proposal will generate noise with the > ML, maybe for nothing. > > On 02/20, Stephane Wirtel wrote: >> Hi, >> >> As you know, Python 3.4 and 3.5 are in security mode and the EOL for >> these versions are respectively 201

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

After discussion with Victor, my proposal will generate noise with the ML, maybe for nothing. On 02/20, Stephane Wirtel wrote: Hi, As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues

Re: [Python-Dev] Question about PEP 484

Hi Sebastian, Both Teddy (cc'd) and I would like to volunteer to help. We're excited about the prospect of an informational pyi PEP. Best, Rebecca On Tue, Jul 17, 2018 at 10:42 AM 'Adam Cataldo' via pytype < pyt...@googlegroups.com> wrote: > Hi Sebastian, > > Of course, we'd be happy to work wi

Re: [Python-Dev] Question about PEP 484

Great Jelle! We look forward to working with you to. On Tue, Jul 17, 2018 at 10:41 AM Jelle Zijlstra wrote: > > > 2018-07-17 9:55 GMT-07:00 Sebastian Rittau : > >> On 17.07.2018 17:05, Guido van Rossum wrote: >> >>> This is a good point. I presume specifying this unambiguously would be a >>> hug

Re: [Python-Dev] Question about PEP 484

Hi Sebastian, Of course, we'd be happy to work with you on this! We just need to figure out which of us will drive this on our end (most likely Rebecca or Teddy). I'll huddle with the team and get back to you with an answer on who later today. On Tue, Jul 17, 2018 at 9:58 AM Sebastian Rittau

Re: [Python-Dev] Question about PEP 484

2018-07-17 9:55 GMT-07:00 Sebastian Rittau : > On 17.07.2018 17:05, Guido van Rossum wrote: > >> This is a good point. I presume specifying this unambiguously would be a >> huge amount of work, and it would mostly codify mypy's current behavior. I >> don't think that's within the scope of PEP 484,

Re: [Python-Dev] Question about PEP 484

On 17.07.2018 17:05, Guido van Rossum wrote: This is a good point. I presume specifying this unambiguously would be a huge amount of work, and it would mostly codify mypy's current behavior. I don't think that's within the scope of PEP 484, but it could well be done as a separate PEP (perhaps a

Re: [Python-Dev] Question about PEP 484

This is a good point. I presume specifying this unambiguously would be a huge amount of work, and it would mostly codify mypy's current behavior. I don't think that's within the scope of PEP 484, but it could well be done as a separate PEP (perhaps an informational one?). I hope you understand that

Re: [Python-Dev] Question about PEP 484

On 16.07.2018 19:21, Adam Cataldo via Python-Dev wrote: * * One thing we care about in particular, given the implementation of pytype, is the detailed definition of what goes in a .pyi file. Do folks think this makes sense to include as part of PEP 484, or would this be better

Re: [Python-Dev] Question about PEP 484

Thanks, Rebecca! So the status of PEP 484 is that we don't want to add new features to it -- those require their own PEP. But we do accept PRs for clarifications, assuming the clarifications are about issues where the intention is clear but the text is not (usually because we thought there was only

Re: [Python-Dev] Question about PEP 484

Hi Guido and all, Let me try to clarify our (pytype team's) intentions a bit. Our overall goal is to see PEP 484 finalized, in the interest of having a definitive type-checking reference to point to and work off of. We're willing and eager to help with this, if we get some guidance on what the aut

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 2:56 PM, Gregory P. Smith wrote: > > On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > >> As one of the authors of PEP 484, *I* never thought there was an >> ambiguity here. The intention was for stub files to conform to the same >> grammar as regular .py files, b

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > As one of the authors of PEP 484, *I* never thought there was an ambiguity > here. The intention was for stub files to conform to the same grammar as > regular .py files, but with a different interpretation. > > > "Have the same syntax as

Re: [Python-Dev] Question about PEP 484

2018-07-16 10:21 GMT-07:00 Adam Cataldo via Python-Dev < python-dev@python.org>: > > > > > > *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering > manager for the Python team at Google. Rebecca Chen, our lead pytype > contributor, and I are int

Re: [Python-Dev] Question about PEP 484

As one of the authors of PEP 484, *I* never thought there was an ambiguity here. The intention was for stub files to conform to the same grammar as regular .py files, but with a different interpretation. > "Have the same syntax as regular Python modules" and "are files containing type hints" are a

Re: [Python-Dev] Question about PEP 484

Thanks Brett and Teddy, Just so it doesn't get lost in the shuffle as folks dive into details, I'll re-ask my earlier question about stub files. Assuming there is consensus that there is ambiguity to resolve in the current definition, is updating the section on stub files the preferred option? The

Re: [Python-Dev] Question about PEP 484

Hi, my name is Teddy Sudol. I work with Adam and Rebecca on pytype. The explanation of stub files is unclear. The section you linked starts with, "Stub files are files containing type hints that are only for use by the type checker, not at runtime." According to https://www.python.org/dev/peps/pep

Re: [Python-Dev] Question about PEP 484

On Mon, 16 Jul 2018 at 10:32 Adam Cataldo via Python-Dev < python-dev@python.org> wrote: > > > > > > *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering > manager for the Python team at Google. Rebecca Chen, our lead pytype > contributor, and I

Re: [Python-Dev] Question on a seemingly useless doctest

Sorry, completely fat-fingered my autocomplete and sent to to wrong list. On Tue, Dec 19, 2017 at 12:12 PM, Erik Bray wrote: > Hi all, > > I have a ticket [1] that's hung up on a failure in one doctest in the > form of sage.doctest.sources.FileDocTestSource._test_enough_doctests. > > This test ha

Re: [Python-Dev] [Question][Asyncio] Process + Threads + asyncio... has sense?

Oks. Thank you very much. --- *Daniel García (cr0hn)* Security researcher and ethical hacker *Personal site*: http://cr0hn.com *Linkedin*: https://www.linkedin.com/in/garciagarciadaniel *Company*: http://abirtone.com *Twitter*: @ggdaniel El día 18 de abril de 2016

Re: [Python-Dev] [Question][Asyncio] Process + Threads + asyncio... has sense?

A better place for this question would be the tulip Google group: https://groups.google.com/forum/#!forum/python-tulip On Mon, Apr 18, 2016 at 3:05 AM, cr0hn wrote: > Hi all, > > It's the first time I write in this list. Sorry if it's not the best place > for this question. > > After I read the

Re: [Python-Dev] Question about the current implementation of str

2016-04-09 9:52 GMT+02:00 Victor Stinner : > But the hash is used as an heuristic to decide if a string is "immutable" or > not, the refcount is also used by the heuristic. If the string is immutable, > an operation like resize must create a new string. I'm talking about this private function: st

Re: [Python-Dev] Question about the current implementation of str

On 09.04.16 10:52, Victor Stinner wrote: Le 9 avr. 2016 03:04, "Larry Hastings" mailto:la...@hastings.org>> a écrit : > Although the str object is immutable from Python's perspective, the C object itself is mutable. For example, for dynamically-created strings the hash field may be lazy-compute

Re: [Python-Dev] Question about the current implementation of str

Le 9 avr. 2016 03:04, "Larry Hastings" a écrit : > Although the str object is immutable from Python's perspective, the C object itself is mutable. For example, for dynamically-created strings the hash field may be lazy-computed and cached inside the object. Yes, the hash is computed once on dema

Re: [Python-Dev] Question about the current implementation of str

On 9 April 2016 at 10:56, Larry Hastings wrote: > > > I have a straightforward question about the str object, specifically the > PyUnicodeObject. I've tried reading the source to answer the question > myself but it's nearly impenetrable. So I was hoping someone here who > understands the current

Re: [Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

On 2016-03-02 18:45, Thomas Wouters wrote: On Wed, Mar 2, 2016 at 3:50 AM, Michael Felt wrote: Hello all, 1) There are many lists to choose from - if this is the wrong one for questions about packaging - please forgive me, and point me in the right direction. It's hard to say where this bel

Re: [Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

On Wed, Mar 2, 2016 at 3:50 AM, Michael Felt wrote: > Hello all, > > 1) There are many lists to choose from - if this is the wrong one for > questions about packaging - please forgive me, and point me in the right > direction. > It's hard to say where this belongs best, but python-list would pro

Re: [Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

On Wed, 2 Mar 2016 at 09:12 Michael Felt wrote: > Hello all, > > 1) There are many lists to choose from - if this is the wrong one for > questions about packaging - please forgive me, and point me in the right > direction. > So in this instance you're after python-list since this is a general su

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

itrou An: python-dev@python.org CC: Gesendet: 11:22 Dienstag, 12.Februar 2013 Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py Le Mon, 11 Feb 2013 11:02:04 -0800, Guido van Rossum a écrit : > Warning: see http://bugs.python.org/issue17170. Depending on the > length of

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

Le Mon, 11 Feb 2013 11:02:04 -0800, Guido van Rossum a écrit : > Warning: see http://bugs.python.org/issue17170. Depending on the > length of the string being scanned and the probability of finding the > specific character, the proposed change could actually be a > *pessimization*. OTOH if the cha

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

Warning: see http://bugs.python.org/issue17170. Depending on the length of the string being scanned and the probability of finding the specific character, the proposed change could actually be a *pessimization*. OTOH if the character occurs many times, the slice will actually cause O(N**2) behavior

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

On Mon, Feb 11, 2013 at 12:16:48PM +, Developer Developer wrote: > I was having a look at the file: Lib/_markupbase.py (@ 82151), function: > "_parse_doctype_element" and have seen something that has caught my attention: > > if '>' in rawdata[j:]: >     return rawdata.find(">", j) + 1 > >

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

Thank you David, I didn't think of the issue tracker. I have just done it. Guido - Ursprüngliche Message - Von: R. David Murray An: Developer Developer CC: "python-dev@python.org" Gesendet: 16:59 Montag, 11.Februar 2013 Betreff: Re: [Python-Dev] Question

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

> Von: Fred Drake > An: Developer Developer > CC: "python-dev@python.org" > Gesendet: 15:10 Montag, 11.Februar 2013 > Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py > > On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer > wrote: > > Would

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

-- Ursprüngliche Message - Von: Fred Drake An: Developer Developer CC: "python-dev@python.org" Gesendet: 15:10 Montag, 11.Februar 2013 Betreff: Re: [Python-Dev] Question regarding: Lib/_markupbase.py On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer wrote: > Wouldn't it

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer wrote: > Wouldn't it be better to do the following? ... > Otherwise I think we are scanning rawdata[j:] twice. Yes, that would be better, and avoids a string object creation as well. -Fred -- Fred L. Drake, Jr. "A storm broke loose in

Re: [Python-Dev] question about packaging

The current effort seems to be distlib, Vinay's project to gather the "good parts" of packaging and distutils as a library API: http://packages.python.org/distlib/ (there's an active bitbucket repo) See https://bitbucket.org/vinay.sajip/distlib/ for the latest code, which is periodically push

Re: [Python-Dev] question about packaging

Antonio Cavallo cavallinux.eu> writes: > Correct if I'm wrong but distlib isn't targeting resources managent? > distutils is targeted to distribute python modules/packages instead; > small differences but on the field they really mean different things. distlib is intended to target more than r

Re: [Python-Dev] question about packaging

> On Dec 29, 2012, at 5:47 AM, Antoine Pitrou wrote: > > The current effort seems to be distlib, Vinay's project to gather the > > "good parts" of packaging and distutils as a library API: > > http://packages.python.org/distlib/ > > (there's an active bitbucket repo) See https://bitbucket.org/vin

Re: [Python-Dev] question about packaging

On Dec 29, 2012, at 5:47 AM, Antoine Pitrou wrote: > On Fri, 28 Dec 2012 17:59:05 -0500 > Doug Hellmann wrote: >> A couple of us from the OpenStack project are interested in getting involved >> in the packaging rewrite/update project. I was following that work for a >> while, but have lost tra

Re: [Python-Dev] question about packaging

Correct if I'm wrong but distlib isn't targeting resources managent? distutils is targeted to distribute python modules/packages instead; small differences but on the field they really mean different things. distlib is under http://hg.python.org/distlib too :O ..my first guess would be that's

Re: [Python-Dev] question about packaging

On Fri, 28 Dec 2012 17:59:05 -0500 Doug Hellmann wrote: > A couple of us from the OpenStack project are interested in getting involved > in the packaging rewrite/update project. I was following that work for a > while, but have lost track of its current state. Can someone point me to the > righ

Re: [Python-Dev] question about packaging

Is that where the discussions are actively happening? Last time I looked at it I thought there was a google group or something. It's bee quite a while, though, so I may just be confused. On Dec 28, 2012, at 6:12 PM, Antonio Cavallo wrote: > There's the distutil mailing list: > > http://mail.py

Re: [Python-Dev] question about packaging

There's the distutil mailing list: http://mail.python.org/mailman/listinfo/distutils-sig Doug Hellmann wrote: A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of i

Re: [Python-Dev] question re: default branch and release clone

And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad? This is the standard for any security fix: such a fix would be added to 3.1.6, 3.2.4, 3.3.1, and 3.4.0, but not to 3.2.3 or 3.3.0. So version(A) > version(B) does not imply has_fix(A, F)

Re: [Python-Dev] question re: default branch and release clone

On 28.08.2012 06:22, Petri Lehtinen wrote: Georg Brandl wrote: Changes to the default branch must be bugfix-only. The 3.4 development only opens when the 3.3 branch is created, which happens after the release of 3.3.0 final. Changes made in default and not cherry-picked to the 3.3.0 release cl

Re: [Python-Dev] question re: default branch and release clone

Georg Brandl wrote: > Changes to the default branch must be bugfix-only. The 3.4 development > only opens when the 3.3 branch is created, which happens after the > release of 3.3.0 final. > > Changes made in default and not cherry-picked to the 3.3.0 release clone > will therefore end up in 3.3.1

Re: [Python-Dev] question re: default branch and release clone

On 26.08.2012 21:15, Chris Jerdonek wrote: Now that the 3.3 release clone has been created, can someone clarify what changes are allowed to go into the default branch? Is it the same policy as if the changes were going into the release clone directly (i.e. code freeze unless you have Georg's app

Re: [Python-Dev] Question

On Sat, Aug 4, 2012 at 4:53 AM, Dheeraj Goswami wrote: > Hi Python Gurus, > I am an experienced Java developer and have been working on it for about 8 > years. I need to build a web 2.0/AJAX based website/application and I am > thinking to build it in Django which means I need to learn and move to

Re: [Python-Dev] Question

On 03/08/2012 19:53, Dheeraj Goswami wrote: Hi Python Gurus, I am an experienced Java developer and have been working on it for about 8 years. I need to build a web 2.0/AJAX based website/application and I am thinking to build it in Django which means I need to learn and move to Python. Please a

Re: [Python-Dev] Question about Module Loading

Nevermind. In 2.6 (what I'm working with) it's "case IMPORT_NAME:" Thank you for letting me know where to start. On 1 June 2011 15:43, Timothy Kadich wrote: > I don't understand what you mean by "TARGET(IMPORT_NAME)". I can't find > that string in ceval.c. > > > On 1 June 2011 12:04, Benjamin Pe

Re: [Python-Dev] Question about Module Loading

I don't understand what you mean by "TARGET(IMPORT_NAME)". I can't find that string in ceval.c. On 1 June 2011 12:04, Benjamin Peterson wrote: > 2011/6/1 Timothy Kadich : > > If a Python program imported a module, say numpy for example, where in > the > > source is this line interpreted and then

Re: [Python-Dev] Question about Module Loading

2011/6/1 Timothy Kadich : > If a Python program imported a module, say numpy for example, where in the > source is this line interpreted and then handled by import.c ? Many different files. Start from TARGET(IMPORT_NAME) in ceval.c. -- Regards, Benjamin _

Re: [Python-Dev] Question about Module Loading

On Wed, 01 Jun 2011 10:54:13 -0700, Timothy Kadich wrote: > If a Python program imported a module, say numpy for example, where in the > source is this line interpreted and then handled by import.c ? Your question is not as simple as you think (I think), but I'm guessing you will want to look at

Re: [Python-Dev] Question about GDB bindings and 32/64 bits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/11/10 16:46, Matthias Klose wrote: > On 26.11.2010 05:11, Jesus Cea wrote: >> I have installed GDB 7.2 32 bits and 32 bits buildslaves are green. >> Nevertheless 64 bits buildslaves are failing test_gdb. >> >> Is there any expectation that a 32 b

Re: [Python-Dev] Question about GDB bindings and 32/64 bits

On 26.11.2010 05:11, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have installed GDB 7.2 32 bits and 32 bits buildslaves are green. Nevertheless 64 bits buildslaves are failing test_gdb. Is there any expectation that a 32 bits GDB be able to debug a 64 bits python?. If not,

Re: [Python-Dev] Question on imports and packages

FWIW, I also agree with Michael that static analysis would be much preferred. You never know what side effects importing a module has. (This could even be construed as an attack vector.) --Guido On Tue, Nov 2, 2010 at 7:54 PM, Brett Cannon wrote: > On Tue, Nov 2, 2010 at 17:35, Guido van Rossum

Re: [Python-Dev] Question on imports and packages

On Tue, Nov 2, 2010 at 17:35, Guido van Rossum wrote: > If you are importing the code, the __module__ attribute on each class > should tell you where it is actually defined (as opposed to where you > imported it from). Then sys.modules gives you the module object which > has a __file__ attribute,

Re: [Python-Dev] Question on imports and packages

On 02/11/2010 23:44, Raymond Hettinger wrote: Brett, Does the import mechanism for importing packages preserve enough information to be able to figure-out where all the components are defined? I'm wondering if it is possible for the class browser to be built-out to scan/navigate class struct

Re: [Python-Dev] Question on imports and packages

If you are importing the code, the __module__ attribute on each class should tell you where it is actually defined (as opposed to where you imported it from). Then sys.modules gives you the module object which has a __file__ attribute, etc. On Tue, Nov 2, 2010 at 4:44 PM, Raymond Hettinger wrote:

Re: [Python-Dev] question/comment about documentation of relative imports

Guido van Rossum wrote: Now it is time to withdraw the anti-recommendation. Or at least re-word them all to make it clear that they're talking about the *old* style of relative import in 2.x. -- Greg ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] question/comment about documentation of relative imports

On Wed, Oct 06, 2010 at 07:09:48AM +1000, Nick Coghlan wrote: > The remaining scenarios we have that can lead to duplication of a > module happen regardless of the import style you use*. > > Cheers, > Nick. > > *For the curious - those scenarios relate to ending up with the same > module present

Re: [Python-Dev] question/comment about documentation of relative imports

On Wed, Oct 6, 2010 at 4:21 AM, Guido van Rossum wrote: > On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: >> The issue is implementing a PEP with nice support for relative >> imports, and then documenting that it should never be used. > > Isn't this mostly historical? Until the new relative-i

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 3:37 PM, Terry Reedy wrote: > On 10/5/2010 2:21 PM, Guido van Rossum wrote: >> >> On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale  wrote: >>> >>> The issue is implementing a PEP with nice support for relative >>> imports, and then documenting that it should never be used. >> >>

Re: [Python-Dev] question/comment about documentation of relative imports

On 10/5/2010 2:21 PM, Guido van Rossum wrote: On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used. Isn't this mostly historical? Until the new relative-import syntax was i

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 11:17 AM, Darren Dale wrote: > The issue is implementing a PEP with nice support for relative > imports, and then documenting that it should never be used. Isn't this mostly historical? Until the new relative-import syntax was implemented there were various problems with re

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, 5 Oct 2010 14:17:47 -0400 Darren Dale wrote: > >> Thats not the point though. Due to compatibility issues, maybe I don't > >> want to expose the code at the top level. Maybe the foo package is > >> distributed elsewhere as a top-level package, but I need to use an > >> older version due to

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 1:45 PM, Antoine Pitrou wrote: > Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit : >> >> >> >> As the OP pointed out, for code that may be *included* in other projects >> >> there is no other choice. This is often useful for packages shared >> >> between one or t

Re: [Python-Dev] question/comment about documentation of relative imports

> If they were actively discouraged, perhaps performing a relative > import would raise a warning, This would be done if this import style was deprecated. It’s different from it being discouraged. > or maybe distutils would raise a warning at install time, Distutils does not inspect source files.

Re: [Python-Dev] question/comment about documentation of relative imports

Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit : > >> > >> As the OP pointed out, for code that may be *included* in other projects > >> there is no other choice. This is often useful for packages shared > >> between one or two projects that nonetheless don't warrant separate > >> dist

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 12:43 PM, Antoine Pitrou wrote: > On Tue, 05 Oct 2010 17:18:18 +0100 > Michael Foord wrote: >> > >> > Generally I'm +0 on relative imports as a whole. >> >> As the OP pointed out, for code that may be *included* in other projects >> there is no other choice. This is often u

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, 05 Oct 2010 17:18:18 +0100 Michael Foord wrote: > > > > Generally I'm +0 on relative imports as a whole. > > As the OP pointed out, for code that may be *included* in other projects > there is no other choice. This is often useful for packages shared > between one or two projects that n

Re: [Python-Dev] question/comment about documentation of relative imports

On 05/10/2010 17:13, Simon Cross wrote: On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote: from ...sys import path Note that while that last case is legal, it is certainly discouraged ("insane" was the word Guido used). Only if by "legal" you mean "happened to work". It stops "happenin

Re: [Python-Dev] question/comment about documentation of relative imports

On Tue, Oct 5, 2010 at 4:56 PM, Darren Dale wrote: >   from ...sys import path > >   Note that while that last case is legal, it is certainly > discouraged ("insane" was the word Guido used). Only if by "legal" you mean "happened to work". It stops "happening to work" in Python 2.6.6. :) General

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

On Wed, Sep 29, 2010 at 5:59 PM, Antoine Pitrou wrote: > Le mercredi 29 septembre 2010 à 17:41 -0400, Chris Bergstresser a > écrit : >> On Wed, Sep 29, 2010 at 5:23 PM, Antoine Pitrou wrote: >> > Anyway, the obvious way to write line-by-line to a bz2 file is to use >> > the BZ2File class! >> >>  

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

Le mercredi 29 septembre 2010 à 17:41 -0400, Chris Bergstresser a écrit : > On Wed, Sep 29, 2010 at 5:23 PM, Antoine Pitrou wrote: > > Anyway, the obvious way to write line-by-line to a bz2 file is to use > > the BZ2File class! > >The BZ2File class does not allow you to open a file for append

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

On Wed, Sep 29, 2010 at 5:23 PM, Antoine Pitrou wrote: > Anyway, the obvious way to write line-by-line to a bz2 file is to use > the BZ2File class! The BZ2File class does not allow you to open a file for appending. Using the incremental encoder does work, which leads to the obvious question

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

On Wed, 29 Sep 2010 23:05:38 +0200 "M.-A. Lemburg" wrote: > > The codec is scheduled to be added back to Python3. > > However, it's main use is in working on whole chunks of > data rather than the line-by-line approach you're after. > This is provided by the codec's incremental encoder/decoders,

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

Chris Bergstresser wrote: > Hi all -- > >I looked through the bug tracker, but I didn't see this listed. I > was trying to use the bz2 codec, but it seems like it's not very > useful in the current form (and I'm not sure if it's getting added > back to py3k, so maybe this is a moot point). I

Re: [Python-Dev] question

On 8/4/2010 3:08 AM, Senthil Kumaran wrote: Hello, Please ask the support questions at: http://groups.google.com/group/comp.lang.python Some people filter out posts from google because of spam. Better gmane.comp.python.general at news.gmane.org or python-list at python.org. -- Terry Jan Reed

Re: [Python-Dev] question

Hello, Please ask the support questions at: http://groups.google.com/group/comp.lang.python This group is for developing python. On Wed, Aug 4, 2010 at 12:13 PM, Sarah Hasanlo Nikfar wrote: > hi > i face with problem when i run one sample on cygwin: > please help me > > Exception happened dur

Re: [Python-Dev] Question for you

Michael Foord wrote: > Hello Connor, > > I think you have the wrong email address - this is Python-dev, an email > list for the development *of* Python. One of the boost specific lists or the general python-list (aka comp.lang.python) would be the place to go for help of this nature. Cheers, Nic

Re: [Python-Dev] Question for you

Hello Connor, I think you have the wrong email address - this is Python-dev, an email list for the development *of* Python. All the best, Michael Foord On 23/02/2010 15:41, Connor, Craig A. wrote: Hello, Dave; My name is Craig Connor and I am a senior s/w developer at Northrop Grumman

Re: [Python-Dev] Question over splitting unittest into a package

On Mon, Jan 4, 2010 at 9:24 AM, Olemis Lang wrote: > On Thu, Dec 31, 2009 at 10:30 AM, Martin (gzlist) > wrote: >> Thanks for the quick response. >> >> On 30/12/2009, Benjamin Peterson wrote: >> >> but maybe a >> discussion could start about a new, less hacky, way of doing the same >> > > I am

Re: [Python-Dev] Question over splitting unittest into a package

On Thu, Dec 31, 2009 at 10:30 AM, Martin (gzlist) wrote: > Thanks for the quick response. > > On 30/12/2009, Benjamin Peterson wrote: >> >> When I made that change, I didn't know that the __unittest "hack" was >> being used elsewhere outside of unittest, so I felt fine replacing it >> with anothe

Re: [Python-Dev] Question over splitting unittest into a package

Thanks for the quick response. On 30/12/2009, Benjamin Peterson wrote: > > When I made that change, I didn't know that the __unittest "hack" was > being used elsewhere outside of unittest, so I felt fine replacing it > with another. While I still consider it an implementation detail, I > would be

Re: [Python-Dev] Question over splitting unittest into a package

Olemis Lang wrote: > PS: `assertRaises` context managers are great !!! BTW > ;o) The detailed comparison methods added for 2.7 are really nice too. It's great getting error messages that tell me what I broke rather than "you broke it!" :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com

Re: [Python-Dev] Question over splitting unittest into a package

2009/12/30 Olemis Lang : > Hmmm ... One of the issues I didn't notice ... > > IMO +1 for leaving it as it was before (i.e. __unittest) because : > >  - the double underscore should mean (CMIIW) that it's an implementation > detail >  - not few libs use that name already ;o) > > +0.5 for adding `__

Re: [Python-Dev] Question over splitting unittest into a package

On Wed, Dec 30, 2009 at 3:04 PM, Benjamin Peterson wrote: > 2009/12/30 Martin (gzlist) : >> Hi Benjamin, > > Hi! > >> In rev 74094 of Python, you split the unittest module up, +1 >> could you >> point me at any bug entries or discussion over this revision so I can >> catch up? > > This was mostl

Re: [Python-Dev] Question over splitting unittest into a package

2009/12/30 Martin (gzlist) : > Hi Benjamin, Hi! > > In rev 74094 of Python, you split the unittest module up, could you > point me at any bug entries or discussion over this revision so I can > catch up? This was mostly a discussion on IRC between Michael Foord and myself. > > As a side-effect

Re: [Python-Dev] question about docstring formatting

David Goodger writes: > Even if there were no supporting tools, I think it is useful to > express the intent of a class/method/function in a single line. The > process of distilling the description down can, in itself, be > illuminating. To imitate the Zen: if the code can't be described in a > s

Re: [Python-Dev] question about docstring formatting

Jeremy Hylton wrote: A question came up at work about docstring formatting. It relates to the description of the summary line in PEP 257. http://www.python.org/dev/peps/pep-0257/ """Multi-line docstrings consist of a summary line just like a one-line docstring, followed by a blank line, follo

Re: [Python-Dev] question about docstring formatting

On Thu, May 28, 2009 at 09:06:03AM -0400, Jeremy Hylton wrote: > It says that the summary line may be used by automatic indexing tools, > but is there any evidence that such a tool actually exists? epydoc, for one. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.

Re: [Python-Dev] question about docstring formatting

On Thu, May 28, 2009 at 09:06, Jeremy Hylton wrote: > A question came up at work about docstring formatting.  It relates to > the description of the summary line in PEP 257. > > http://www.python.org/dev/peps/pep-0257/ > """Multi-line docstrings consist of a summary line just like a > one-line doc

Re: [Python-Dev] question about docstring formatting

On 01:06 pm, jer...@alum.mit.edu wrote: It says that the summary line may be used by automatic indexing tools, but is there any evidence that such a tool actually exists? Or was there once upon a time? If there are no such tools, do we still think that it is important that it fits on line line

  1   2   >