[Python-Dev] (no subject)

RANK SLOBODNIK NAME STANISLAV FRST NAME SMOLEC BINARY 15.03/1983 IDENTIFICATION NUMBER 830315/6081 ADDRESS KUČIŠDORFSKÁ DOLINA NUMBER HOME 6144/704 CITY PEZINOK COUNTRY SLOVAKIA ZIP CODES 90201 EUROPE COMPANY 4KA SLOVAKIA MY CALL NUMBER +421949281444 COMPANY MICROSOFT MY E-MAIL

[Python-Dev] (no subject)

Thanks for the review! > In short, I propose: > def cutprefix(self: str, prefix: str, /) -> str: > if self.startswith(prefix) and prefix: > return self[len(prefix):] > else: > return self > > I call startswith() before testing if pre is non-empty to inherit of >

[Python-Dev] (no subject)

Hi, FYI Yury Selivanov just proposed PEP 603 which is now discussed at: https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318 PEP-603: Adding a frozenmap type to collections https://www.python.org/dev/peps/pep-0603/ I don't have a strong preference between python-dev

Re: [Python-Dev] (no subject)

On 2019-04-10 22:00, Terry Reedy wrote: On 4/10/2019 7:24 AM, Robert Okadar wrote: Hi community, I have developed a tkinter GUI component, Python v3.7. It runs very well in Linux but seeing a huge performance impact in Windows 10. While in Linux an almost real-time performance is achieved, in

Re: [Python-Dev] (no subject)

On 4/10/2019 7:24 AM, Robert Okadar wrote: Hi community, I have developed a tkinter GUI component, Python v3.7. It runs very well in Linux but seeing a huge performance impact in Windows 10. While in Linux an almost real-time performance is achieved, in Windows it is slow to an unusable level.

Re: [Python-Dev] (no subject)

Hi Steven, Thank you for pointing me in the right direction. Will search for help on places you mentioned. Not sure how can we help you with developing the Python interpreter, as I doubt we have any knowledge that this project might use it. When I say 'we', I mean on my colleague and me. All

Re: [Python-Dev] (no subject)

Hi Robert, This mailing list is for the development of the Python interpreter, not a general help desk. There are many other forums where you can ask for help, such as the comp.lang.python newsgroup, Stackoverflow, /r/python on Reddit, the IRC channel, and more. Perhaps you can help us

[Python-Dev] (no subject)

Hi community, I have developed a tkinter GUI component, Python v3.7. It runs very well in Linux but seeing a huge performance impact in Windows 10. While in Linux an almost real-time performance is achieved, in Windows it is slow to an unusable level. The code is somewhat stripped down from the

[Python-Dev] (no subject)

-- في 8 سبتمبر ، 2017 في تمام الساعة 12:30 بعد منتصف الليل ، سيقوم Masayuki YAMAMOTO < ma3yuki.8mamo10 at gmail.com > كتب: > *مرحبا يا قوم، * > > *I إرسال PEP 539 المسودة الثالثة للالنهاية. شكرا لجميع النصائح * >

Re: [Python-Dev] (no subject)

On Tue, Dec 26, 2017 at 2:01 AM, Yogev Hendel wrote: > > I don't know if this is the right place to put this, > but I've found the following lines of code results in an incredibly long > processing time. > Perhaps it might be of use to someone. > > import re > pat =

Re: [Python-Dev] (no subject)

On 2017-12-26 07:01, Yogev Hendel wrote: I don't know if this is the right place to put this, but I've found the following lines of code results in an incredibly long processing time. Perhaps it might be of use to someone. /import re/ /pat = re.compile('^/?(?:\\w+)/(?:[%\\w-]+/?)+/?$')/

[Python-Dev] (no subject)

I don't know if this is the right place to put this, but I've found the following lines of code results in an incredibly long processing time. Perhaps it might be of use to someone. *import re* *pat = re.compile('^/?(?:\\w+)/(?:[%\\w-]+/?)+/?$')*

Re: [Python-Dev] (no subject)

Victor, Thanks - I will comment on the issue WRT backporting the fix. If you have particular issues you’d like me to look into, just point me in the right direction. Thanks, Rob On 6/30/17, 2:29 AM, "Victor Stinner" wrote: >Hi Robb, > >2017-06-29 23:34 GMT+02:00

[Python-Dev] (no subject)

Hi Robb, 2017-06-29 23:34 GMT+02:00 Rob Boehne : > I¹m new to the list, and contributing to Python specifically, and I¹m > interested in getting master and 3.6 branches building and working > ³better² on UNIX. > I¹ve been looking at a problem building 3.6 on HP-UX and see a

[Python-Dev] (no subject)

Thanks to Nick Coghlan and Barry Warsaw we've setup a new SIG dedicated to discussing python features from different distributions point of view. Here is Nick's reasoning: > With the Python 3 migration, and the growth in interest in user level > package management for development purposes, what

Re: [Python-Dev] (no subject)

I am still in favor of this PEP but have run out of time to review it and the feedback. I'm going on vacation for a week or so, maybe I'll find time, if not I'll start reviewing this around Feb 23. -- --Guido van Rossum (python.org/~guido) ___

Re: [Python-Dev] (no subject)

I split off a separate thread on python-ideas [1] specific to the idea of introducing + and += operators on a dict. [1] https://mail.python.org/pipermail/python-ideas/2015-February/031748.html ~ Ian Lee On Tue, Feb 10, 2015 at 10:35 PM, John Wong gokoproj...@gmail.com wrote: On Wed, Feb

Re: [Python-Dev] (no subject)

John Wong wrote: I am actually amazed to remember dict + dict is not possible... there must be a reason (performance??) for this... I think it's mainly because there is no obviously correct answer to the question of what to do about duplicate keys. -- Greg

Re: [Python-Dev] (no subject)

On 02/10/2015 10:33 AM, Paul Moore wrote: On 10 February 2015 at 00:29, Neil Girdhar mistersh...@gmail.com wrote: function(**kw_arguments, **more_arguments) If the key key1 is in both dictionaries, more_arguments wins, right? There was some debate and it was decided that duplicate keyword

Re: [Python-Dev] (no subject)

On Wed, Feb 11, 2015 at 12:35 AM, Ian Lee ianlee1...@gmail.com wrote: +1 for adding + or | operator for merging dicts. To me this operation: {'x': 1, 'y': 2} + {'z': 3} {'x': 1, 'y': 2, 'z': 3} Is very clear. The only potentially non obvious case I can see then is when there are

Re: [Python-Dev] (no subject)

Georg Brandl wrote: The call syntax part is a mixed bag: on the one hand it is nice to be consistent with the extended possibilities in literals (flattening), but on the other hand there would be small but annoying inconsistencies anyways (e.g. the duplicate kwarg case above). That

Re: [Python-Dev] (no subject)

On Wed, 11 Feb 2015 18:45:40 +1300 Greg Ewing greg.ew...@canterbury.ac.nz wrote: Antoine Pitrou wrote: bytearray(ba) + bbc bytearray(b'abc') ba + bytearray(bbc) b'abc' It's quite convenient. It's a bit disconcerting that the left operand wins, rather than one of them being

Re: [Python-Dev] (no subject)

On Mon, 09 Feb 2015 18:06:02 -0800 Ethan Furman et...@stoneleaf.us wrote: On 02/09/2015 05:14 PM, Victor Stinner wrote: def partial(func, *args, **keywords): def newfunc(*fargs, **fkeywords): return func(*(args + fargs), **keywords, **fkeywords) ... return newfunc

Re: [Python-Dev] (no subject)

On 2/9/2015 7:29 PM, Neil Girdhar wrote: For some reason I can't seem to reply using Google groups, which is is telling this is a read-only mirror (anyone know why?) I presume spam prevention. Most spam on python-list comes from the read-write GG mirror. -- Terry Jan Reedy

Re: [Python-Dev] (no subject)

Le 10 févr. 2015 06:48, Greg Ewing greg.ew...@canterbury.ac.nz a écrit : It could potentially be a little more efficient by eliminating the construction of an intermediate list. Is it the case in the implementation? If it has to create a temporary list/tuple, I will prefer to not use it. After

Re: [Python-Dev] (no subject)

On 10.02.15 04:06, Ethan Furman wrote: return func(*(args + fargs), **{**keywords, **fkeywords}) We don't use [*args, *fargs] for concatenating lists, but args + fargs. Why not use + or | operators for merging dicts? ___ Python-Dev mailing

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 19:04:03 +1300 Greg Ewing greg.ew...@canterbury.ac.nz wrote: Donald Stufft wrote: perhaps a better solution is to simply make it so that something like ``a_list + an_iterable`` is valid and the iterable would just be consumed and +’d onto the list. I don't

Re: [Python-Dev] (no subject)

On 10 February 2015 at 01:48, Donald Stufft don...@stufft.io wrote: I am really really -1 on the comprehension syntax. [... omitting because gmail seems to have messed up the quoting ...] I don’t think * means “loop” anywhere else in Python and I would never “guess” that [*item for item in

Re: [Python-Dev] (no subject)

On 10 February 2015 at 00:29, Neil Girdhar mistersh...@gmail.com wrote: function(**kw_arguments, **more_arguments) If the key key1 is in both dictionaries, more_arguments wins, right? There was some debate and it was decided that duplicate keyword arguments would remain an error (for now at

Re: [Python-Dev] (no subject)

On 10/02/2015 13:23, Antoine Pitrou wrote: On Tue, 10 Feb 2015 23:16:38 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 10 Feb 2015 19:24, Terry Reedy tjre...@udel.edu wrote: On 2/9/2015 7:29 PM, Neil Girdhar wrote: For some reason I can't seem to reply using Google groups, which is is

Re: [Python-Dev] (no subject)

+1 for adding + or | operator for merging dicts. To me this operation: {'x': 1, 'y': 2} + {'z': 3} {'x': 1, 'y': 2, 'z': 3} Is very clear. The only potentially non obvious case I can see then is when there are duplicate keys, in which case the syntax could just be defined that last setter

Re: [Python-Dev] (no subject)

Antoine Pitrou wrote: bytearray(ba) + bbc bytearray(b'abc') ba + bytearray(bbc) b'abc' It's quite convenient. It's a bit disconcerting that the left operand wins, rather than one of them being designated as the wider type, as occurs with many other operations on mixed types, e.g. int +

Re: [Python-Dev] (no subject)

Donald Stufft wrote: 1. The statement *item is roughly the same thing as (item[0], item[1], item[n]) No, it's not -- that would make it equivalent to tuple(item), which is not what it means in any of its existing usages. What it *is* roughly equivalent to is item[0], item[1], item[n]

Re: [Python-Dev] (no subject)

Victor Stinner wrote: Le 10 févr. 2015 06:48, Greg Ewing greg.ew...@canterbury.ac.nz mailto:greg.ew...@canterbury.ac.nz a écrit : It could potentially be a little more efficient by eliminating the construction of an intermediate list. Is it the case in the implementation? If it has to

Re: [Python-Dev] (no subject)

On 10 Feb 2015 19:24, Terry Reedy tjre...@udel.edu wrote: On 2/9/2015 7:29 PM, Neil Girdhar wrote: For some reason I can't seem to reply using Google groups, which is is telling this is a read-only mirror (anyone know why?) I presume spam prevention. Most spam on python-list comes from

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 1:33 AM, Paul Moore p.f.mo...@gmail.com wrote: On 10 February 2015 at 00:29, Neil Girdhar mistersh...@gmail.com wrote: function(**kw_arguments, **more_arguments) If the key key1 is in both dictionaries, more_arguments wins, right? There was some debate and it

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 23:16:38 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 10 Feb 2015 19:24, Terry Reedy tjre...@udel.edu wrote: On 2/9/2015 7:29 PM, Neil Girdhar wrote: For some reason I can't seem to reply using Google groups, which is is telling this is a read-only mirror (anyone

Re: [Python-Dev] (no subject)

On 10 Feb 2015 19:41, Paul Moore p.f.mo...@gmail.com wrote: I agree completely with Donald here. The comprehension syntax has consistently been the part of the proposal that has resulted in confused questions from reviewers, and I don't think it's at all intuitive. Is it allowable to vote

Re: [Python-Dev] (no subject)

On Feb 9, 2015, at 8:34 PM, Neil Girdhar mistersh...@gmail.com wrote: On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft don...@stufft.io mailto:don...@stufft.io wrote: On Feb 9, 2015, at 7:29 PM, Neil Girdhar mistersh...@gmail.com mailto:mistersh...@gmail.com wrote: For some reason

Re: [Python-Dev] (no subject)

Donald Stufft wrote: perhaps a better solution is to simply make it so that something like ``a_list + an_iterable`` is valid and the iterable would just be consumed and +’d onto the list. I don't think I like the asymmetry that this would introduce into + on lists. Currently [1, 2, 3]

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 1:31 AM, Donald Stufft don...@stufft.io wrote: On Feb 10, 2015, at 12:55 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Donald Stufft wrote: However [*item for item in ranges] is mapped more to something like this: result = [] for item in iterable:

Re: [Python-Dev] (no subject)

Donald Stufft wrote: However [*item for item in ranges] is mapped more to something like this: result = [] for item in iterable: result.extend(*item) Actually it would be result.extend(item) But if that bothers you, you could consider the expansion to be result = [] for item in

Re: [Python-Dev] (no subject)

Le 10 févr. 2015 03:07, Ethan Furman et...@stoneleaf.us a écrit : That line should read return func(*(args + fargs), **{**keywords, **fkeywords}) to avoid the duplicate key error and keep the original functionality. To me, this is just ugly. It prefers the original code which use

Re: [Python-Dev] (no subject)

On 02/09/2015 05:14 PM, Victor Stinner wrote: def partial(func, *args, **keywords): def newfunc(*fargs, **fkeywords): return func(*(args + fargs), **keywords, **fkeywords) ... return newfunc The new code behaves differently since Neil said that an error is raised if

Re: [Python-Dev] (no subject)

On 02/09/2015 05:48 PM, Donald Stufft wrote: I don’t think * means “loop” anywhere else in Python and I would never “guess” that [*item for item in iterable] meant that. It’s completely non intuitive. Anywhere else you see *foo it’s unpacking a tuple not making an inner loop. That

Re: [Python-Dev] (no subject)

On Feb 10, 2015, at 12:55 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Donald Stufft wrote: However [*item for item in ranges] is mapped more to something like this: result = [] for item in iterable: result.extend(*item) Actually it would be result.extend(item) But if

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner victor.stin...@gmail.com wrote: To be logic, I expect [(*item) for item in mylist] to simply return mylist. If you want simply mylist as a list, that is [*mylist] [*(item) for item in mylist] with mylist=[(1, 2), (3,)] could return [1, 2, 3],

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 2:08 AM, Victor Stinner victor.stin...@gmail.com wrote: Le 10 févr. 2015 03:07, Ethan Furman et...@stoneleaf.us a écrit : That line should read return func(*(args + fargs), **{**keywords, **fkeywords}) to avoid the duplicate key error and keep the original

Re: [Python-Dev] (no subject)

To be logic, I expect [(*item) for item in mylist] to simply return mylist. [*(item for item in mylist] with mylist=[(1, 2), (3,)] could return [1, 2, 3], as just [*mylist], so unpack mylist. Victor ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] (no subject)

ah, sorry… forget that I said just as it is now — I am losing track of what's allowed in Python now! On Tue, Feb 10, 2015 at 2:29 AM, Neil Girdhar mistersh...@gmail.com wrote: On Tue, Feb 10, 2015 at 2:20 AM, Victor Stinner victor.stin...@gmail.com wrote: To be logic, I expect [(*item) for

Re: [Python-Dev] (no subject)

For some reason I can't seem to reply using Google groups, which is is telling this is a read-only mirror (anyone know why?) Anyway, I'm going to answer as best I can the concerns. Antoine said: To be clear, the PEP will probably be useful for one single line of Python code every 1. This

Re: [Python-Dev] (no subject)

What's an example of a way inspect.signature must change? I thought PEP 448 added new unpacking shortcuts which (for example) change the *caller* side of a function call. I didn't realize it impacted the *callee* side too. //arry/ On 02/09/2015 03:14 PM, Antoine Pitrou wrote: On Tue,

Re: [Python-Dev] (no subject)

Yes, that's exactly right. It does not affect the callee. Regarding function call performance, nothing has changed for the originally accepted argument lists: the opcodes generated are the same and they are processed in the same way. Also, regarding calling argument order, not any order is

Re: [Python-Dev] (no subject)

On Feb 9, 2015, at 7:29 PM, Neil Girdhar mistersh...@gmail.com wrote: For some reason I can't seem to reply using Google groups, which is is telling this is a read-only mirror (anyone know why?) Anyway, I'm going to answer as best I can the concerns. Antoine said: To be clear, the

Re: [Python-Dev] (no subject)

On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote: Also, regarding calling argument order, not any order is allowed. Regular arguments must precede other kinds of arguments. Keyword arguments must precede **-args. *-args must precede **-args. However, I agree with Antoine that PEP 8 should be

Re: [Python-Dev] (no subject)

The admonition is against syntax that currently exists. On Mon, Feb 9, 2015 at 7:53 PM, Barry Warsaw ba...@python.org wrote: On Feb 09, 2015, at 07:46 PM, Neil Girdhar wrote: Also, regarding calling argument order, not any order is allowed. Regular arguments must precede other kinds of

Re: [Python-Dev] (no subject)

Just an FYI: http://www.reddit.com/r/Python/comments/2v8g26/python_350_alpha_1_has_been_released/ 448 was mentioned here (by Python lay people — not developers). On Mon, Feb 9, 2015 at 7:56 PM, Neil Girdhar mistersh...@gmail.com wrote: The admonition is against syntax that currently exists.

Re: [Python-Dev] (no subject)

2015-02-10 1:29 GMT+01:00 Neil Girdhar mistersh...@gmail.com: For some reason I can't seem to reply using Google groups, which is is telling this is a read-only mirror (anyone know why?) Anyway, I'm going to answer as best I can the concerns. Antoine said: To be clear, the PEP will

[Python-Dev] (no subject)

Hello all, The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently completed by Joshua Landau and me. The issue tracker http://bugs.python.org/issue2292 has a working patch.

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 16:34, Ethan Furman wrote: On 02/09/2015 01:28 PM, Benjamin Peterson wrote: On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008)

Re: [Python-Dev] (no subject)

FWIW, I've encouraged Neil and others to complete this code as a prerequisite for a code review (but I can't review it myself). I am mildly in favor of the PEP -- if the code works and looks maintainable I would accept it. (A few things got changed in the PEP as a result of the work.) On Mon, Feb

Re: [Python-Dev] (no subject)

On 02/09/2015 01:28 PM, Benjamin Peterson wrote: On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently completed by Joshua

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 16:32, Guido van Rossum wrote: FWIW, I've encouraged Neil and others to complete this code as a prerequisite for a code review (but I can't review it myself). I am mildly in favor of the PEP -- if the code works and looks maintainable I would accept it. (A few things

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: Hello all, The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently completed by Joshua Landau and me. The issue tracker

Re: [Python-Dev] (no subject) PEP 448

On Mon, 9 Feb 2015 16:06:20 -0500 Neil Girdhar mistersh...@gmail.com wrote: Hello all, The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently completed by Joshua Landau and

Re: [Python-Dev] (no subject) PEP 448

2015-02-10 0:51 GMT+01:00 Antoine Pitrou solip...@pitrou.net: The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently completed by Joshua Landau and me. To be clear, the PEP

Re: [Python-Dev] (no subject)

On Feb 9, 2015, at 4:06 PM, Neil Girdhar mistersh...@gmail.com wrote: Hello all, The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/ https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and

Re: [Python-Dev] (no subject)

On 10 Feb 2015 08:13, Benjamin Peterson benja...@python.org wrote: On Mon, Feb 9, 2015, at 16:34, Ethan Furman wrote: On 02/09/2015 01:28 PM, Benjamin Peterson wrote: On Mon, Feb 9, 2015, at 16:06, Neil Girdhar wrote: The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/)

Re: [Python-Dev] (no subject)

Right, Just to be clear though: **-args must follow any *-args and position arguments. So at worst, your example is: f(x, y, *k, *b, c, **w, **d) Best, Neil On Mon, Feb 9, 2015 at 5:10 PM, Benjamin Peterson benja...@python.org wrote: On Mon, Feb 9, 2015, at 16:32, Guido van Rossum

Re: [Python-Dev] (no subject)

On Tue, 10 Feb 2015 08:43:53 +1000 Nick Coghlan ncogh...@gmail.com wrote: For example, the potential for arcane call arguments suggests the need for a PEP 8 addition saying first standalone args, then iterable expansions, then mapping expansions, even though syntactically any order would now

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote: Right, Just to be clear though: **-args must follow any *-args and position arguments. So at worst, your example is: f(x, y, *k, *b, c, **w, **d) Best, Ah, I guess I was confused by this sentence in the PEP: Function calls

Re: [Python-Dev] (no subject)

That wording is my fault. I'll update the PEP to remove the word currently after waiting a bit to see if there are any other problems. Best, Neil On Mon, Feb 9, 2015 at 6:16 PM, Benjamin Peterson benja...@python.org wrote: On Mon, Feb 9, 2015, at 17:12, Neil Girdhar wrote: Right,

Re: [Python-Dev] (no subject)

Hi, 2015-02-09 22:06 GMT+01:00 Neil Girdhar mistersh...@gmail.com: The updated PEP 448 (https://www.python.org/dev/peps/pep-0448/) is implemented now based on some early work by Thomas Wouters (in 2008) and Florian Hahn (2013) and recently completed by Joshua Landau and me. I don't like this

Re: [Python-Dev] (no subject)

On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft don...@stufft.io wrote: On Feb 9, 2015, at 7:29 PM, Neil Girdhar mistersh...@gmail.com wrote: For some reason I can't seem to reply using Google groups, which is is telling this is a read-only mirror (anyone know why?) Anyway, I'm going to

Re: [Python-Dev] (no subject)

Donald Stufft wrote: why is: print(*[1], *[2], 3) better than print(*[1] + [2] + [3])? It could potentially be a little more efficient by eliminating the construction of an intermediate list. defining + or | or some other symbol for something similar to [1] + [2] but for dictionaries. This

[Python-Dev] (no subject)

How closely is tokenize.detect_encoding() supposed to match PyTokenizer_FindEncoding()? From what I can tell, there is a subtle difference in their behavior that has bearing on PEP 263 handling during import. [1] Should any difference be considered a bug, or should I work around it? Thanks.

Re: [Python-Dev] (no subject)

Am 19.04.2012 10:00, schrieb Eric Snow: How closely is tokenize.detect_encoding() supposed to match PyTokenizer_FindEncoding()? From what I can tell, there is a subtle difference in their behavior that has bearing on PEP 263 handling during import. [1] Should any difference be considered a

[Python-Dev] (no subject)

Guido posted this on Google+: IEEE/ISO are working on a draft document about Python vulunerabilities: http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf (in the context of a larger effort to classify vulnerabilities in all languages: ISO/IEC TR

Re: [Python-Dev] (no subject)

The authors are definitely interested in feedback! Best probably to post it to my G+ thread. On Mon, Dec 12, 2011 at 1:44 PM, Eric Snow ericsnowcurren...@gmail.com wrote: Guido posted this on Google+: IEEE/ISO are working on a draft document about Python vulunerabilities:

[Python-Dev] (no subject)

Using:Python 2.7.0+ (r27:82500, Sep 15 2010, 18:14:55) [GCC 4.4.5] on linux2(Ubuntu 10.10) Method to reproduce error: 1. Defining a module which is later imported by another: - class SomeThing: def __init__(self):

Re: [Python-Dev] (no subject)

On Mon, Jan 24, 2011 at 04:39:54PM +, Stefan Spoettl wrote: So it may be that the Python interpreter isn't working correctly onlyon Ubuntu 10.10 Than you should report the problem to the Ubuntu developers, right? And it would be nice if you investigate deeper and send a proper mail -

Re: [Python-Dev] (no subject)

Bug reports should be filed at bugs.python.org On Mon, Jan 24, 2011 at 08:39, Stefan Spoettl spoe...@hotmail.com wrote: Using: Python 2.7.0+ (r27:82500, Sep 15 2010, 18:14:55) [GCC 4.4.5] on linux2 (Ubuntu 10.10) Method to reproduce error: 1. Defining a module which is later imported by

[Python-Dev] (no subject)

Hi. I have an issue which has been annoying me from quite sometime and any help would be greatly appreciated: I just installed Python 2.6 on my centOS 5 system and then I installed nltk. Now I am running a certain python script and it gives me this error- ImportError: No module named _sqlite3

Re: [Python-Dev] (no subject)

Hi! This mailing list is about developing Python itself, not about developing *in* Python or debugging Python installations. Try seeing help elsewhere, such as on the comp.lang.python newsgroup, #python IRC channel on freenode, or other sources (check the wiki if you need any others). Thanks,

Re: [Python-Dev] (no subject)

Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing

[Python-Dev] (no subject)

___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (no subject)

On Mon 15/03/10 4:34 AM , Martin v. Löwis mar...@v.loewis.de sent: So, just to be clear about the my bug report, it is directly related to the problem of overlapping I/O requests with CPU-bound processing. This kind of scenario comes up in the context of many applications--especially those

Re: [Python-Dev] (no subject)

Martin v. Löwis martin at v.loewis.de writes: What do you think of creating a buildbot category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Do you have any specific reports that you would want to classify

[Python-Dev] (no subject)

Christian, When will the third party library versions be finalized for Py3k? For the time being I am building with: bzip2-1.0.3 db-4.4.20 openssl-0.9.8g sqlite-source-3.3.4 tcl8.4.12 tix-8.4.0 tk8.4.12 I had an slight issue with the PCbuild9 solution with OpenSSL, I will open a bug and

[Python-Dev] (no subject)

I was hoping you guys would consider creating function in os.path or otherwise that would find the full path of a file when given only it's base name and nothing else.I have been made to understand that this is not currently possible.If it is in any can you please inform me of it[i know this

Re: [Python-Dev] (no subject)

JOSHUA ABRAHAM wrote: I was hoping you guys would consider creating function in os.path or otherwise that would find the full path of a file when given only it's base name and nothing else.I have been made to understand that this is not currently possible. Does os.path.abspath() do what

Re: [Python-Dev] (no subject)

On 4/30/07, Greg Ewing [EMAIL PROTECTED] wrote: JOSHUA ABRAHAM wrote: I was hoping you guys would consider creating function in os.path or otherwise that would find the full path of a file when given only it's base name and nothing else.I have been made to understand that this is not

[Python-Dev] (no subject)

Mr. Rossum, I saw an old post you made about the Google Internships (Jan 25,2006). As a prospective for next summer, you mention that it would be in my best interest to contact brett Cannon. I have many questions I'd love to have answered, how do I go about contacting him? I look forward

[Python-Dev] (no subject)

Jim Jewet writes: I can't imagine [a conditional] expression small enough that [requiring] parentheses really hurt. var = t if c else f var = (t if c else f) This is a good example. I'm now +1 on adding this to PEP 8. I'm +0 on adding it to the grammer... in the long run it's

[Python-Dev] (no subject)

anybody here? bob 2611 s highway 101 san diego, ca 92007 209 984 0880 http://evdo-coverage.com/cell-phone-antenna-booster.html -- Robert Q Kim, Wireless Internet Advisor http://evdo-coverage.com/cellular-repeater.html http://hsdpa-coverage.com 2611 S. Pacific Coast Highway 101 Suite

[Python-Dev] (no subject)

sir i have taken softwer from icashline.com that is mass mailing softwere is worldcast that is not running it is showing that I/O PROBLEM OR MEDIA PRO BLEM.PLEASE HELP ME.Send instant messages to your online friends http://in.messenger.yahoo.com

Re: [Python-Dev] (no subject)

On 11/24/05, Duncan Grisby [EMAIL PROTECTED] wrote: Hi, I posted this to comp.lang.python, but got no response, so I thought I would consult the wise people here... I have encountered a problem with the re module. I have a multi-threaded program that does lots of regular expression

Re: [Python-Dev] (no subject)

On Thu, 2005-11-24 at 14:11 +, Duncan Grisby wrote: Hi, I posted this to comp.lang.python, but got no response, so I thought I would consult the wise people here... I have encountered a problem with the re module. I have a multi-threaded program that does lots of regular expression

Re: [Python-Dev] (no subject)

Donovan Baarda wrote: I don't know if this will help, but in my experience compiling re's often takes longer than matching them... are you sure that it's the match and not a compile that is taking a long time? Are you using pre-compiled re's or are you dynamically generating strings and using

[Python-Dev] (no subject)

Mixing Decimal and float is nearly ALWAYS a user error. Doing it correctly requires significant expertise in the peculiarities of floating point representations. So that I think user should declare floats explicitly (###.###f) - he will fall into float space only if he wish it. So Python

  1   2   >